ASP.NET Core 3.1 Web API Hosting and deployment in IIS


I was just recently deploying a ASP.NET Core 3.1 web API project to IIS and decided to write a post on issues faced. Before that let’s understand the difference between Kestrel and IIS briefly.

The Kestrel web server is a new web server as part of ASP.NET Core. It is now the preferred web server for all new ASP.NET applications.

Why do we need the new Kestrel Web Server? What about IIS?

IIS does literally anything and everything as a web server. It is infinitely configurable with ASP.NET handlers & modules via the ASP.NET integrated pipeline. It has robust management APIs for configuration and deployment but it is not the fastest web server around. Lightweight web servers like Node.js and Netty (it is a networking library for Java) make IIS look old and slow.

.NET community was able to start over from scratch and created Kestrel Web Server. Kestrel is considered a preferred web server for newer ASP.NET applications. Keeping their past knowledge community build the simplest and fastest web server possible. ASP.NET Core & Kestrel combined are a whole new request pipeline for how ASP.NET requests work. Things like HTTP modules & handlers have been replaced with simple middleware. The entire System.Web namespace is gone. ASP.NET Core & Kestrel have been designed from the ground to take advantage of async.

Background: Kestrel is based on libuv, which you might know if you have spent some time with NodeJS. Shortly put libuv is an asynchronous I/O library, which used a single threaded event loop model and has efficient async sockets support on Windows, OSX and Linux. Kestrel only uses libuv for I/O work and supports running multiple event loops, so all other work is done in managed code on standard .NET worker threads and optimized to reduce the number of SYS calls to a minimum.

Kestrel is the default web server specified by the ASP.NET Core project templates.

By itself as an edge server processing requests directly from a network, including the Internet.

With a reverse proxy server, such as Internet Information Services (IIS), Nginx, or Apache. A reverse proxy server receives HTTP requests from the Internet and forwards them to Kestrel.

Either hosting configuration—with or without a reverse proxy server—is supported. For Kestrel configuration guidance and information on when to use Kestrel in a reverse proxy configuration, see Kestrel web server implementation in ASP.NET Core.

Hosting Models in IIS for ASP.NET Core

When you deploy your web application to IIS, various requests to the application are handled by what is known as ASP.NET Core Module. Under default settings the hosting model for your application is InProcess. This means ASP.NET Core Module forwards the requests to IIS HTTP Server (IISHttpServer). The IIS HTTP Server is a server that runs in-process with IIS. In-process models bypasses built-in Kestrel web server of ASP.NET Core.

If you decide to use Out-Of-Process hosting model then IIS HTTP Server won’t be used. Instead Kestrel web server is used to process your requests. So, ASP.NET Core Module forwards your requests to Kestrel web server.

Steps to Deploy Web API in IIS:

1. Verify if IIS is enabled in Windows features if not install/enable IIS

2. Download and install Asp.Net core runtime & dotnet core hosing bubdle

3. Verify AspNetCoreModules in IIS Manager modules after installation

Here AspNetCoreModule is v2.1.17 &  AspNetCoreModuleV2 is v3.1.3

4. Create Asp.Net core 3.1 project in visual studio and after developing it, publish it

Select Advanced to change deployment mode to Self-Contained to include all project deployment files.

Based on the Target Runtime you selected here, you should also change in IIS app pool advanced settings to Enable 32-Bit Applications to true or false other wise you may see ”HTTP Error 500.32 – ANCM Failed to Load dll”

Save it with the changes in advanced settings and create profile and publish

5. Add new Application pool in IIS Manager

6. Add new Website as Core313

7. Browse website http://localhost:90/ to test

As I mentioned above Target framework is set to x86 & in IIS, we haven’t enabled the option for “Enable 32 Bit Applications” to true. Now change it accordingly.

Once again browse to website http://localhost:90/WeatherForecast to test


You may also like


Leave a Reply

Your email address will not be published.