Hi there,
I have experience the above issue. When I issue the dotnet lambda deploy-serverless
command, this is what I get:
dotnet lambda package
Executing publish command
Deleted previous publish folder
... invoking 'dotnet publish', working folder 'C:\Users\blurb\Desktop\x_xW\Bleep\Bleep\Bleep\bin\Release\netcoreapp1.0\publish'
... publish: Publishing Bleep for .NETCoreApp,Version=v1.0
... publish: Project Utilities (.NETStandard,Version=v1.6) was previously compiled. Skipping compilation.
... publish: Project UserService (.NETStandard,Version=v1.6) was previously compiled. Skipping compilation.
... publish: Project ConfigurationService (.NETStandard,Version=v1.6) was previously compiled. Skipping compilation.
... publish: Project EmailService (.NETStandard,Version=v1.6) was previously compiled. Skipping compilation.
... publish: Project MembershipService (.NETStandard,Version=v1.6) was previously compiled. Skipping compilation.
... publish: Project OrganisationService (.NETStandard,Version=v1.6) was previously compiled. Skipping compilation.
... publish: Project GeographyService (.NETStandard,Version=v1.6) was previously compiled. Skipping compilation.
... publish: Project Bleep (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
... publish: publish: Published to C:\Users\blurp\Desktop\x_xW\Bleep\Bleep\Bleep\bin\Release\netcoreapp1.0\publish
... publish: Published 1/1 projects successfully
Error: Project is referencing NETStandard.Library version 2.0.0. Max version supported by netcoreapp1.0 is 1.6.0.
Error: Check the following dependencies for versions compatible with netcoreapp1.0:
Error: Amazon.Lambda.APIGatewayEvents : 1.1.0
Error: Amazon.Lambda.Serialization.Json : 1.1.0
Error: JWT : 3.0.2
Error: Newtonsoft.Json : 10.0.3
Error: ConfigurationService : 1.0.0
Error: EmailService : 1.0.0
Error: GeographyService : 1.0.0
Error: MembershipService : 1.0.0
Error: OrganisationService : 1.0.0
Error: UserService : 1.0.0
Error: Utilities : 1.0.0
Failed to create application package
From my limited understanding, dotnet publish
is successful, but for some reason the lambda package
portion failed.
It seems to me that the command will fail if there are libraries attaching to the netcoreapp project.
Please help.
Thanks in advance.
Can you share the the Bleep.deps.json file from the publish folder? That should help us figure out what is triggering the tooling to think what depending on .NET Standard 2.0. I can see that JWT 3.0.2 and Newtonsoft.Json 10.0.3 require dependencies that are only available as part of .NET Core 1.1.
Thanks @normj ,
Here's the project.json
for Bleep
:
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": false
},
"dependencies": {
"Amazon.Lambda.Core": "1.0.0",
"Amazon.Lambda.APIGatewayEvents": "1.1.0",
"Amazon.Lambda.Serialization.Json": "1.1.0",
"Amazon.Lambda.Tools": {
"type": "build",
"version": "1.7.0"
},
"Newtonsoft.Json": "10.0.3",
"Utilities": "1.0.0-*",
"ConfigurationService": "1.0.0-*",
"EmailService": "1.0.0-*",
"MembershipService": "1.0.0-*",
"OrganisationService": "1.0.0-*",
"UserService": "1.0.0-*",
"GeographyService": "1.0.0-*",
"Microsoft.NETCore.App": {
"type": "platform",
"version": "2.0.0"
}
},
"tools": {
"Amazon.Lambda.Tools": "1.7.0"
},
"frameworks": {
"netcoreapp1.0": {
"imports": "dnxcore50"
}
}
}
Ah, the error message
Error: Project is referencing NETStandard.Library version 2.0.0. Max version supported by netcoreapp1.0 is 1.6.0.
is caused but your project referencing 2.0.0 of Microsoft.NETCore.App which stands for .NET Core 2.0. That should be 1.0.0.
The other error:
Check the following dependencies for versions compatible with netcoreapp1.0
Is most likely caused by Newtonsoft.Json and JWT packages which bring reference .NET Core 1.1 dependencies. Newtonsoft.Json is an easy one you change the reference to 9.0.1. JWT I don't see a compatible version. All the 3.X versions reference NETStandard.Library 1.6.1 which is .NET Core 1.1.
You said it works when you deploy from Visual Studio? Do the functions actually run correctly or did they just deploy successfully?
You said it works when you deploy from Visual Studio? Do the functions actually run correctly or did they just deploy successfully?
@normj : Yes, we have tested the api-endpoints to these functions and they are working.
@normj , this is the part that puzzles me. Why should we haves these function deployed, and working using the AWS Tool GUI when I can even get it pakaged using dotnet lambda
?
I assuming the deployment in Visual Studio is working because your toolkit version is a bit out of date. We added this check into the tooling a couple months back. The problem is when you include dependencies that their NuGet spec file says depend on .NET Core 1.1 dependencies you get unpredictable results. Usually it fails but sometimes in your case it will work because the NuGet package doesn't use any platform specific code.
I think the version check is important because more often than not developers deploy functions that pull in .NET Core 1.1 dependencies and then things fail at runtime with confusing error messages. I am willing to add a command line switch to the tooling to disable the version check for users willing to take the risk and do the extra testing.
I pushed out version 1.7.1 which has a new --disable-version-check
that you can use to turn off the version check.
dotnet package deploy-function --disable-version-check true
Use this at your own risk. You will notice in your publish folder there will be a lot of System dlls that get put in by the dotnet publish
command because of libraries declaring dependencies to .NET Core 1.1.
Thanks for the hard work, @normj !
Closing as I believe this is resolved. I'm not planning on exposing the switch in the Visual Studio GUI but if you need it from VS you could add the switch in the aws-lambda-tools-defaults.json file.
Most helpful comment
I pushed out version 1.7.1 which has a new
--disable-version-check
that you can use to turn off the version check.dotnet package deploy-function --disable-version-check true
Use this at your own risk. You will notice in your publish folder there will be a lot of System dlls that get put in by the
dotnet publish
command because of libraries declaring dependencies to .NET Core 1.1.