Recently, I tried to deploy .NET Core applications to IIS on Windows 10 and Windows 11. But I ended up with the error: HTTP Error 500.31 – Failed to load ASP.NET Core runtime.
But I managed to figure out the reason behind this error and also solved this. I thought it worth sharing it with you here so that you can resolve it too.
In my experience, I faced a challenging issue while deploying an ASP.NET Core application on IIS. Upon navigating to the site, I was greeted with a “HTTP Error 500.31 – Failed to load ASP.NET Core runtime” message. This error typically points to problems with the Microsoft.NetCore.App or Microsoft.AspNetCore.App versions. My investigation into the system event log revealed errors indicating missing application dependencies and the absence of ‘aspnetcorev2_inprocess.dll’. Despite having other .NET Core 3.1 sites running smoothly and trying various fixes, this particular issue persisted. The similarity in settings between the functioning and non-functioning sites made it difficult to pinpoint the cause of the problem.
Why did this error happen?
In the situation I encountered, the core of the problem was that the target computer did not have the ASP.NET Core runtime installed.
How did I fix that?
The problem was successfully resolved once I installed the Hosting Bundle for .Net Core 3.1.
Update: At that time, that was the latest version but for now you can follow the second below link
Here is the link: Download .NET Core 3.1 (Linux, macOS, and Windows) (microsoft.com)
Here is the latest version as of now: Download .NET 8.0 (Linux, macOS, and Windows) (microsoft.com)
To download any version click: .NET Downloads (Linux, macOS, and Windows) (microsoft.com)
My issue stemmed from mistakenly installing only the runtime instead of the full hosting bundle. I had assumed that clicking the “x64” link would download the x64 version of the bundle, but it turned out that it didn’t.
Click on “Hosting Bundle“
Another solution:
I encountered the same error messages while setting up a new .NET Core 3.1 framework-dependent web app on an IIS server that was already hosting similar apps without issues. The Event Viewer’s messages were a bit different and hard to trace. Converting the site to “win-x86” worked, unlike “win-x64”.
After extensive troubleshooting — reviewing Microsoft’s linked information, running the site via command line, checking .NET configurations on both IIS and build servers, and examining various settings — I discovered the issue was related to an AppPool setting.
Specifically, it was the “Enable 32-Bit Applications” setting in the AppPool’s Advanced Settings. In my case, it was set to True, but changing it to False resolved the issue. This setting was True due to the “IIS AppPool – Create” step in our deployment process with octopusdeploy, which defaults to True. Disable it to solve the issue.