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.
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.
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,