Aws-lambda-dotnet: ASP.NET Core 1.1 deploys to AWS Elastic Beanstalk successfully but the app url gives an error

[saf-itpro]

After installing your toolkit from here and using the menu Publish to AWS Elastic Beanstalk... in VS2017, I successfully published a very simple sample ASP.NET Core 1.1 app (created using this official tutorial). But when I click on the URL of the app in the AWS Elastic Beanstalk console I get the error: HTTP Error 502.5 - Process Failure. I'm using the AWS AIM user in a group that has the following permissions in AWS: SystemAdministrator, AmazonEC2FullAccess, AWSElasticBeanstalkFullAccess.

When I download the logs from EC2 instance, I see the following:

EventLog Application:

2017-03-22T04:33:51.000Z Error 0:(0) IIS AspNetCore Module - Application 'MACHINE/WEBROOT/APPHOST/DEFAULT WEB SITE' with physical root 'C:\inetpub\AspNetCoreWebApps\app\' failed to start process with commandline '"dotnet" .\AWS_WebApp.dll', ErrorCode = '0x80004005 : 80008083.

NOTE: App runs fine locally on VS2017 using built-in IISExpress. And, although the local copy of the app is using small SQL Express db but the local app's home page is not using db and opens fine even if I stop the SQL Express Services on my local machine.

[normj]

With the new GA tooling of .NET Core it implicitly adds a dependency on the latest patch version of the framework for your target framework. So if you are targeting .NET Core 1.0 it implicitly adds dependency to 1.0.4 and if you target .NET Core 1.1 it adds a dependency to 1.1.1 which both came out last week and the beanstalk AMI haven't been updated yet.

The beanstalk AMI will get updated once the Beanstalk team finishes their testing and verification but till then you need override the implicit dependency in your project. To do that edit your csproj file and add the following element in your PropertyGroup section where the target framework is specified.

For .NET Core 1.0

<RuntimeFrameworkVersion>1.0.3</RuntimeFrameworkVersion>

For .NET Core 1.1

<RuntimeFrameworkVersion>1.1.0</RuntimeFrameworkVersion>

Full example for context:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
    <RuntimeFrameworkVersion>1.1.0</RuntimeFrameworkVersion>
  </PropertyGroup>

  ...

</Project>

We are looking into how we can improve this situation when new .NET Core patches versions are released.

[saf-itpro]

@normj Thank you for providing a workaround. It works now. I don't know if it matters, I noticed that when the project was open in VS2017 and when I edited the csproj file (using your suggested example above) in Notepad, a warning in VS2017 appeared as follows: Detected package downgrade: Microsoft.NETCore.App from 1.1.1 to 1.1.0. However when I recompiled the project warning disappeared.

Suggestion: You may want to add your suggested solution to your AWS Blog here and all other relevant places since this issue took me for a wild ride (LOL) as no one else (that I contacted) could understand the issue. Some even thought my deployment was wrong. And, thank you for providing the ToolKit for VS2017.

[normj]

The beanstalk AMI have been updated with the latest version of .NET Core. I'm going to close this as the issue has gone away. I'll work with the Beanstalk team to better handle future .NET Core updates.

[xingzhougmu]

@normj , I deployed my web app to AWS Elastic Beanstalk successfully but the app url gives an error:
2017-08-29T11:24:16.000Z Error 0:(0) IIS AspNetCore Module - Application 'MACHINE/WEBROOT/APPHOST/DEFAULT WEB SITE' with physical root 'C:\inetpub\AspNetCoreWebApps\DysonChatBot\' failed to start process with commandline 'dotnet .\DysonChatbot.dll', ErrorCode = '**0x80004005** : 8000808c.

Any idea what the error means? BTW, I can deploy the same web app to Azure and works there.

[normj]

Is it possible to remote into the EC2 instance and check the event viewer? That will probably give details about why the dotnet process is dying.

[xingzhougmu]

@normj thanks for the suggestion. I have figured out that the issue is caused by the incomplete package when zip up.

[mrdavenz]

@xingzhougmu I have the same issue, care to elaborate further so others can fix the problem also?

[xingzhougmu]

@mrdavenz my issue is with the package I zipped. I run "zip output.zip *" which will not include files from sub-folder. After I use "zip -r output.zip *" my issue is gone.