One of the most convenient options for hosting an ASP.NET Core application is to utilize IIS. You can easily set up IIS on Windows-based servers. As such IIS makes for a good host for your ASP.NET Core applications.
ASP.NET Core Module and Hosting Models
The ASP.NET Core Module is a native IIS module that plugs into the IIS pipeline, allowing ASP.NET Core applications to work with IIS. Run ASP.NET Core apps with IIS by either:
- Hosting an ASP.NET Core app inside of the IIS worker process (
w3wp.exe
), called the in-process hosting model.
- Forwarding web requests to a backend ASP.NET Core app running the Kestrel server, called the out-of-process hosting model.
There are trade-offs between each of the hosting models. By default, the in-process hosting model is used due to better performance and diagnostics.
In-process Hosting Model
In-process hosting runs an ASP.NET Core app in the same process as its IIS worker process. In-process hosting provides improved performance over out-of-process hosting because requests aren't proxied over the loopback adapter, a network interface that returns outgoing network traffic back to the same machine.
The following diagram illustrates the relationship between IIS, the ASP.NET Core Module, and an app hosted in-process:
The general flow of a request is as follows:
- A request arrives from the web to the kernel-mode HTTP.sys driver.
- The driver routes the native request to IIS on the website's configured port, usually 80 (HTTP) or 443 (HTTPS).
- The ASP.NET Core Module receives the native request and passes it to IIS HTTP Server (
IISHttpServer
). IIS HTTP Server is an in-process server implementation for IIS that converts the request from native to managed.
After the IIS HTTP Server processes the request:
- The request is sent to the ASP.NET Core middleware pipeline.
- The middleware pipeline handles the request and passes it on as an
HttpContext
instance to the app's logic.
- The app's response is passed back to IIS through IIS HTTP Server.
- IIS sends the response to the client that initiated the request.
CreateDefaultBuilder
adds an IServer instance by calling the UseIIS method to boot the CoreCLR and host the app inside of the IIS worker process (w3wp.exe
or iisexpress.exe
).
Since ASP.NET Core 3.0, in-process hosting has been enabled by default for all app deployed to IIS.
To explicitly configure an app for in-process hosting, set the value of the <AspNetCoreHostingModel>
property to InProcess
in the project file (.csproj
):
<PropertyGroup>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup>
Out-process Hosting Model
Because ASP.NET Core apps run in a process separate from the IIS worker process, the ASP.NET Core Module handles process management. The module starts the process for the ASP.NET Core app when the first request arrives and restarts the app if it shuts down or crashes.
The following diagram illustrates the relationship between IIS, the ASP.NET Core Module, and an app hosted out-of-process:
- Requests arrive from the web to the kernel-mode HTTP.sys driver.
- The driver routes the requests to IIS on the website's configured port. The configured port is usually 80 (HTTP) or 443 (HTTPS).
- The module forwards the requests to Kestrel on a random port for the app. The random port isn't 80 or 443.
The ASP.NET Core Module specifies the port via an environment variable at startup. The UseIISIntegration extension configures the server to listen on http://localhost:{PORT}
. Additional checks are performed, and requests that don't originate from the module are rejected. The module doesn't support HTTPS forwarding. Requests are forwarded over HTTP even if received by IIS over HTTPS.
After Kestrel picks up the request from the module, the request is forwarded into the ASP.NET Core middleware pipeline. The middleware pipeline handles the request and passes it on as an HttpContext
instance to the app's logic. Middleware added by IIS Integration updates the scheme, remote IP, and pathbase to account for forwarding the request to Kestrel. The app's response is passed back to IIS, which forwards it back to the HTTP client that initiated the request.
When building a host in CreateHostBuilder
(Program.cs
), call CreateDefaultBuilder to enable IIS integration.