Many Windows hosting providers run ASP.NET Core applications on IIS. Publishing is simple, but when the app does not start the errors say little. Here is what we learned in production.

Framework-dependent or self-contained?

• Framework-dependent: small package, but the right runtime (Hosting Bundle) must be installed on the server.
• Self-contained: the runtime travels with the application. Bigger package, but no dependency on the server: ideal on shared hosting.

dotnet publish -c Release -r win-x64 --self-contained true -o ./publish

In-process

With the in-process model the application runs inside the IIS process: it is the fastest. The web.config file generated by publishing tells the ASP.NET Core module which executable to start.

Updating without locked files

Copying an app_offline.htm file into the site folder makes the module stop the application and show that page: you replace the DLLs and then remove the file. Before removing it, check that the copied files are complete.

When 500.30 appears

Error 500.30 means the application was started but failed during startup. To find out where:

1. Enable stdout logs in web.config (stdoutLogEnabled="true") in a writable folder.
2. Write a log to file as the very first statement of Program.cs: if it does not appear, the problem is before your code.
3. For runtime loading problems, the COREHOST_TRACE environment variable produces a detailed host trace.

A lesson about dependencies

Removing a NuGet package can change the version of libraries that came in indirectly through that package, and therefore the binary produced. Before every release compare the deps.json file and the DLL's references with the version in production, and if needed pin the versions of transitive dependencies explicitly in the project.