You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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 packageAmazon.Lambda.Core
. This will give us an error at restore-time if we're using packages of newer runtimes.The text was updated successfully, but these errors were encountered: