AWS Lambda uses netstandard 1.3 can we downgrade Windsor from netstandard 1.6?

[ghost]

The package Amazon.Lambda.Core uses netstandard1.3 from NuGet and it also has runtime dependencies on:

• System.Runtime 4.1.0
• System.Console
• System.IO

Can we downgrade the current implementation to netstandard 1.3 and System.X 4.1?

[Kralizek]

So the problem is that AWS lambda supports only .NET Core 1.0.
Microsoft made kind of a mess with versioning so that you get automatically brought from 1.0 to 1.1 by simply referencing the package NETStandard.Library 1.6.1.
As @fir3pho3nixx wrote in this issue, System.X 4.3.0 point to .NET Core 1.1.

[jonorossi]

Can we downgrade the current implementation to netstandard 1.3 and System.X 4.1?

As I mentioned in #145: "We had to go with .NET Standard 1.6 to use Microsoft.Extensions.DependencyModel until we move to .NET Standard 2.0 in the future", other than that there are probably a heap of other missing APIs. According to the docs .NET Core 1.0 supports .NET Standard 1.6.

So it sounds like the problem is not .NET Standard 1.6 but which version of System.* packages.

Looking at the build output it is definitely testing against .NET Core 1.0:

Installing runtime.win7-x64.Microsoft.NETCore.DotNetHost 1.0.1.

However, I see NETStandard.Library 1.6.1 being added to the nuspec of the output which we didn't add. Do we just need to ensure we don't use 4.3.0 versions of System.* packages, or maybe if we manually add NETStandard.Library 1.6.0 would that work?

you get automatically brought from 1.0 to 1.1 by simply referencing the package NETStandard.Library 1.6.1

This is the part I'm still unclear about, how does this actually happen, I meant what in the package definition causes .NET Core 1.1 to be required, and how do we know which packages we can actually use?

[ghost]

As I mentioned in #145: "We had to go with .NET Standard 1.6 to use Microsoft.Extensions.DependencyModel until we move to .NET Standard 2.0 in the future"

Here be a skeleton. Could perhaps flag this as a FEATURE_??? symbol and have a go at trying this?

However, I see NETStandard.Library 1.6.1 being added to the nuspec of the output which we didn't add. Do we just need to ensure we don't use 4.3.0 versions of System.* packages, or maybe if we manually add NETStandard.Library 1.6.0 would that work?

MsBuild does not like this, it says A PackageReference for 'NETStandard.Library' was included in your project. This package is implicitly referenced by the .NET SDK and you do not typically need to reference it from your project.

This is the part I'm still unclear about, how does this actually happen, I meant what in the package definition causes .NET Core 1.1 to be required, and how do we know which packages we can actually use?

+1 We should investigate more.

[Kralizek]

I'm looking forward for an issue in the aws/aws-lambda-dotnet repo about this issue. basically there is a property in the project file used to specify the version of the NETStandard.Library package to be intrinsically included. Maybe @normj can help us on the issue?

Anyway, Lambda supports .NET Core 1.0 which is an implementation of .NET Standard 1.6, that means any library written for any version of .NET Standard up to 1.6 (included) will work on Lambda.

EDIT: I found this issue that mentions the implicitly added packages: dotnet/sdk#764

[jonorossi]

I'm completely guessing here based on reading a few GitHub issues around the place, but it seems like it was a .NET Core 1.x tooling mistake for libraries to implicitly have NETStandard.Library added as a dependency, and .NET Core 2.x tooling will no longer add it for executables.

You could disable the NETStandard.Library dependency from being included as a dependency of your NuGet package without disabling the implicit reference entirely with the following:

<ItemGroup>
    <PackageReference Update="NETStandard.Library" PrivateAssets="true" />
</ItemGroup>

This will happen automatically when targeting .NET Standard 2.0 or higher: dotnet/sdk#1171

(Domysee/Pather.CSharp#3 (comment))

Or we could use DisableImplicitFrameworkReferences, no idea what either actually does under the hood to cause it not to be added.

[jonorossi]

@fir3pho3nixx I still believe it is the right decision to use Microsoft.Extensions.DependencyModel rather than loading any and all DLLs in the bin directory. It doesn't appear .NET Standard 1.6 is a problem here anyway.

[ghost]

I might just dust off my hello world aws function, manually compile windsor from master and kick it up there to see what errors we get. Also should we raise an issue with the AWS lambda team to upgrade? (Surprised this has not been done already).

[ghost]

I can get a string from a resolved from a service here using AWS Lambda in VS2017.

This is using the same dependencies as the intended netstandard release of Windsor here.

This is my screen shot when I run it from Visual Studio:

Closing.

[jonorossi]

@fir3pho3nixx great to hear, I guess that means we don't have anything blocking a release.

@Kralizek would love to hear from you before we make the release.

[Kralizek]

@jonorossi it looks like the test done by @fir3pho3nixx is a good evidence that v4 will run on Lambda without any issue. I'll try to work on another test during the afternoon (right now it's 11:40 here in Sweden)

Anyway, thanks a lot for the attention to this specific use case :)

[normj]

Late to the issue but here is what I have learned from developing the AWS Lambda libraries.

To force the project to use .NET Standard Library 1.6.0 the .NET Core 1.0 implementation add the following to the csproj. By default VS uses 1.6.1.

<NetStandardImplicitPackageVersion>1.6.0</NetStandardImplicitPackageVersion>

[jonorossi]

Thanks @normj, however it appears (@fir3pho3nixx test above) we don't need to force NETStandard.Library 1.6.0 and 1.6.1 works, unless you know something we don't.

[jonorossi]

FYI I'm going to cut the release tomorrow.

[normj]

Locking to 1.6.0 would be ideal but seeing as there is a dependency to System.Runtime.Serialization.Formatters which only has versions dependent on NETStandard.Libary 1.6.1 I'm not sure that is feasible.

What happens when your project depends on 1.6.1 and is being used on a netcoreapp1.0 the publish folder will end up containing a lot of the system libraries like System.Net.HttpClient.dll and System.Threading.dll. So in @fir3pho3nixx case his simple function which should only contains his project dll and Windsor ends up being about 8 megs worth of stuff. Also I'm sure there will be cases this will fail when you get to more advanced cases because the .NET Core loader will end up loading the packaged up system dlls instead of the versions we compiled for the Lambda environment.

[jonorossi]

@normj thanks for more info, I still don't understand the underlying change Microsoft made that causes the incompatibility, however I also came across this issue (aws/aws-lambda-dotnet#129) which provides some info on referencing the Amazon.Lambda.Tools package which is related.

seeing as there is a dependency to System.Runtime.Serialization.Formatters which only has versions dependent on NETStandard.Libary 1.6.1 I'm not sure that is feasible

That is what I've concluded too, and with Castle.Core 4.1.0 already depending on NETStandard.Library 1.6.1+ I think we just have to leave it as is. Also with so many libraries moving across to the new .NET SDK tooling (from project.json tooling) heaps of libraries are coming along with a NETStandard.Library 1.6.1+ dependency including:

• https://www.nuget.org/packages/Castle.Core/4.1.0
• https://www.nuget.org/packages/Newtonsoft.Json/10.0.2
• https://www.nuget.org/packages/NodaTime/2.0.0
• https://www.nuget.org/packages/Moq/4.7.49
• https://www.nuget.org/packages/Microsoft.Extensions.DependencyInjection/1.1.0
• https://www.nuget.org/packages/Microsoft.AspNetCore/1.1.0

This really is just something AWS will have to solve if they want their customers using .NET Core on Lambda, or I guess they wait until .NET Core 2.0 is out as it'll be an LTS release.