Aws-lambda-dotnet: Solving the issue of NETStandard.Library 1.6.1

Created on 6 Jun 2017  路  3Comments  路  Source: aws/aws-lambda-dotnet

I guess we all know the pain brought onto us by the poor versioning of the package NETStandard.Library 1.6.1.

I know the latest versions of Amazon.Lambda.Tools solved it at deploy-time, but I wonder if there is a reason why the simple package version constraint wouldn't work?

I am thinking of something like <PackageReference Include="NETStandard.Library" Version="[1.6.0]" /> added to the package Amazon.Lambda.Core. This will give us an error at restore-time if we're using packages of newer runtimes.

guidance

Most helpful comment

IS this referencing the fact that deplying to AWS throws?:
Project is referencing NETStandard.Library version 1.6.1. Max version supported by netcoreapp1.0 is 1.6.0.

If so, what is the solution? I have not been able to get it resolved.

Thanks,

All 3 comments

IS this referencing the fact that deplying to AWS throws?:
Project is referencing NETStandard.Library version 1.6.1. Max version supported by netcoreapp1.0 is 1.6.0.

If so, what is the solution? I have not been able to get it resolved.

Thanks,

@JNBarnes I guess you have no other solution than using .NET Core 1.0 and therefore use the package (directly or indirectly) with the version 1.6.0.

That is an interesting idea. I was playing around with it and you really don't get a very helpful error messages. This is what I got when I tried it out.

Package restore failed. Rolling back package changes for 'AWSLambda1'.

I'd rather give our messaging during deployment then get issues opened about why I can't restore a package.

Was this page helpful?
0 / 5 - 0 ratings