Publishing ASP.NET Core Applications to Azure Action Pack Hosting

The more I work with ASP.NET Core, the more I love the new way of doing things. We have far better language features to help make life easier, however, with all good, there is some bad. Compilation and deployment are something that still is just a bit more complicated than it should be. In the past few weeks, I've been working on getting a practical, full-featured application deployed under ASP.NET Core. One of the hardest parts was getting the application published to my hosting environment. Everything would run locally just fine, but for one reason or another, I would not be able to get things working as expected on the hosting provider. Compile & Publish would finish in my automated environment without error, yet files were missing. Finally, I managed to figure out what was going wrong, so I thought I'd share it.  

The Hosting Provider

In my case, I was working to deploy to GearHost, which is using a solution similar to the Azure Action Pack framework. I've also tried the following steps to deploy to Windows Azure, and it works perfectly. Your mileage to other solutions may vary.

The Starting Point

The project solution that I had was built inside of Visual Studio 2017, as all .NET Core projects. One data tier assembly, one service assembly, and one MVC Core project. Locally, it ran and executed perfectly! I had a CI build process that would compile and publish to the win10x64 target without any issues. Deployment to the hosting provider would result in failure, with no real detail other than "process failed to start."

Fixing the Issue

In the end, the issue was that my projects were missing a definition of the target runtime identifiers. By default, projects do not have any set target, my compilation targeting a particular runtime simply "skipped" it and resulted in a successful build. In the end, I added the following inside of EACH .csproj file within the solution.

<propertygroup>
  <runtimeidentifiers>win10-x64</runtimeidentifiers>
</propertygroup>

No changes were visible in Visual Studio as part of my build process after doing this.

Proper Build & Publish

With the proper runtime identifiers set, I was able to improve my build script to target the identifier. My initial configuration had an improper target runtime. The below script is my final restore, build, and publish.

dotnet restore -v Minimal -r win10-x64
dotnet publish FlightFiles.Web -c Release -r win10-x64 --output C:\Published

In the end, it is simple. We restore everything, targeting win10-x64, then we publish our web application as a release publish outputting to a specific directory. We can then copy this to our hosting provider and we are set to go!

Summary

It was very simple in the end to get the application running. However, it does require a manual review and edit of each project. Target runtimes are also very sensitive, and missing/improper runtime values don't result in errors as you might expect. Hope this helps!