ASP.NET Core Out Of Process Hosting

Back to: ASP.NET Core Tutorials For Beginners and Professionals

ASP.NET Core Out of Process Hosting

In this article, I will discuss the ASP.NET Core Out-of-Process Hosting Model with Examples. Before proceeding, I strongly recommend you read the ASP.NET Core InProcess Hosting and Kestrel Web Server in ASP.NET Core Web Application articles.

What is Out of Process Hosting in ASP.NET Core?

In the Out-of-Process Hosting model, the ASP.NET Core application runs in a separate worker process from the web server worker process that handles the incoming HTTP requests. This is different from the In-Process hosting model, where the application runs within the same worker process as the web server.

With Out-of-Process Hosting model, IIS or other web servers such as Apache or Nginx serve as reverse proxy, receiving incoming HTTP requests and then forwarding them to an internal server, Kestrel. So, in the case of the Out-of-Process Hosting Model, there are two web servers.

• External Web Server: This server is commonly IIS (Internet Information Services) on Windows but can also be Apache or Nginx on other platforms. It acts as a reverse proxy, managing incoming HTTP/HTTPS requests from clients. This server’s primary responsibilities are dealing with client requests, load balancing, and security layers. If everything is fine, it forwards the coming HTTP requests to the Internal Web Server, i.e., Kestrel.
• Internal Web Server (Kestrel): Kestrel is the default cross-platform web server for ASP.NET Core applications. It runs the ASP.NET Core application, i.e., the Kestrel web server processes the request and generates a response.

This separation allows the Internal web server (Kestrel) to be optimized for handling .NET Core application code execution while the external web server deals with client requests, load balancing, and security layers.

How Do We Configure the OutofProcess Hosting in ASP.NET Core Application?

We can configure the out-of-process hosting in two ways in ASP.NET Core.

Method 1: Using Project Properties File

In this case, we need to add the <AspNetCoreHostingModel> element to the applications project file with a value of OutOfProcess. So, open the Project Properties file and copy and paste the following code.

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
  </PropertyGroup>
</Project>

Method 2:  Specify the Hosting Model as OutOfProcess using GUI

To do so, right-click on your project in the Solution Explorer and click on the Properties option from the context menu, which will open the Project Properties window. Select the Debug tab from this window and click on the Open debug launch profiles UI button, as shown in the image below.

Once you click on the Open debug launch profiles UI button, the Launch Profile window will open. From this window, select IIS Express and scroll down. Somewhere, you will find the Hosting Model drop-down list with the following values. As we have already set OutOfProcess as our hosting model in the Project Properties window, the Out of Process Hosting Model is selected as the default hosting model.

How Do We Use Out-of-Process Hosting in ASP.NET Core?

Remember that if we use the HTTP or HTTPS profiles to run our application, neither the InProcess nor the OutOfProcess hosting model will be involved. In that case, Kestrel is the only web server that will host and run the application. The InProcess and OutOfProcess hosting models will come into play when we launch the application using the IIS Express launch profile in Visual Studio.

Using IIS Express as the profile in Visual Studio, the application uses either In-Process or Out-of-Process hosting, depending on the configuration.

• Running with Kestrel Alone: If the application is run directly through HTTP or HTTPS profiles, Kestrel is the only server involved, handling both the incoming requests and application processing.
• Out-of-Process Hosting with IIS: IIS receives client requests and, instead of processing them directly, forwards them to Kestrel, which processes the request by running the application code. IIS then returns Kestrel’s response to the client.

Kestrel as Internet-Facing Web Server (External Web Server)

Suppose the application is run directly using HTTP or HTTPS profiles without an external web server (such as IIS, Apache, or Nginx). In that case, Kestrel will be the only web server involved, as shown in the diagram.

In this scenario:

• Kestrel Web Server will handle both incoming HTTP requests and process the application code.
• Kestrel will act as the Internet-facing web server, receiving requests directly from the Internet, processing them by executing the ASP.NET Core application code, and returning responses directly to the client.
• In this case, no external web server (such as IIS, Apache, or Nginx) is used, meaning Kestrel serves both as the application host and the HTTP server.

Worker Process Name in Kestrel?

The worker process that runs Kestrel depends on the deployment mode:

• If the application is deployed as Framework-Dependent, the worker process name will be dotnet.exe. This means the application relies on the .NET runtime installed on the host machine to execute.
• If the application is deployed as Self-Contained, the worker process name will be the application’s name. For example, if the project name is FirstCoreWebApplication, the worker process name will be FirstCoreWebApplication.exe (Windows).

Run the application using HTTP/HTTPS Launch Profile:

Let us prove this. First, modify the Program class as follows:

namespace FirstCoreWebApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            // Step 1: Creating the Web Host and Services
            var builder = WebApplication.CreateBuilder(args);

            //Step 2: Building the Application
            var app = builder.Build();

            //Step 3: Setting Up Endpoints, Routing and Middleware Components
            app.MapGet("/", () => "Worker Process Name : " + System.Diagnostics.Process.GetCurrentProcess().ProcessName);

            //Step 4: Running the Application
            app.Run();
        }
    }
}

Now, run the application using either the http or https profiles and verify the worker process name, as shown in the image below. Here, it shows FirstCoreWebApplication, meaning Kestrel Server executes our application code.

Now, you can also verify the server that processes the request using the browser developer tool, as shown in the image below. Here, you can see that Kestrel is the Web Server that handles the request.

This proves that when we use the HTTP or HTTPS profile to launch our application in Visual Studio, Kestrel is the only Web Server that hosts our application, handles the incoming HTTP Requests, and executes the application code. In this case, Kestrel works as an Internet-facing Web Server.

Kestrel as Internal Web Server

Kestrel can also be used as an Internal Web Server. It can be used with a Reverse Proxy (Internet Facing Server) such as IIS, Apache, or Nginx. Now, the question that should come to your mind is, if Kestrel can be used as a Web Server that can directly handle and process the incoming HTTP Request, why do we need a Reverse Proxy Server?

This is because the Reverse Proxy Server provides an additional layer of configuration, load balancing, URL Rewriting, and security, which is not available with the Kestrel Server. The Kestrel Server’s main job is to execute the application code in Cross-Platform. So, a good choice is using the Kestrel Web Server along with a Reverse Proxy Server such as IIS, Apache, or Nginx.

How Does the Out-Of-Process Hosting Model Work?

The Out-of-Process Hosting Model comes into play when an ASP.NET Core application is hosted using IIS (or other web servers like Apache or Nginx) but runs separately in its own process. The external web server acts as a reverse proxy server, forwarding requests to the internal Kestrel server.

Once the Kestrel Server receives the request, it will process the request with its own worker process, generate the response, and send the response back to the Reverse Proxy Server, which then sends the response back to the requested client over the Internet who initially made the request. For a better understanding, please have a look at the following diagram.

Let us understand how the Out-of-Process Hosting Model works.

Step 1: Internet (User’s Request)

This is where the user interacts with the web application. The process begins with the client making an HTTP request to the server hosting the application. For example, a user could access a website or call an API through their browser or some other client. The user’s browser sends an HTTP request over the internet to the IIS web server.

Step 2: IIS (Internet Information Services)

IIS is the external web server that first receives the incoming request. IIS acts as a reverse proxy server and uses the ASP.NET Core Module (ANCM) to forward the request to the Kestrel server that hosts the ASP.NET Core application.

Step 3: ASP.NET Core Module (ANCM)

The ASP.NET Core Module (ANCM) is a component within IIS that manages interaction between IIS and the Kestrel server running the ASP.NET Core application. It ensures that the Kestrel Web Server runs and forwards incoming requests to Kestrel. Specifically:

• ANCM checks if the Kestrel server is up and running.
• If the Kestrel server is not running, ANCM starts it.
• Once the Kestrel server is up, ANCM forwards the HTTP request to Kestrel for further processing.

Step 4: Kestrel Web Server

Kestrel is the internal web server for the ASP.NET Core application, and it handles the HTTP requests forwarded by ANCM. Here is what happens:

• Kestrel receives the HTTP request from ANCM.
• Kestrel processes the HTTP request and forwards it to the Application Code, which handles the business logic and generates a response.

Step 5: Application Code (ASP.NET Core Application)

This is where the ASP.NET Core application’s logic is executed. The application code includes controllers, services, and middleware components to handle the request. The ASP.NET Core Middleware Pipeline processes the request. Some tasks handled at this stage include

• Authentication/Authorization: Verifying whether the user has access to the resource.
• Routing: Determining which controller and action method should handle the request.
• Any other custom middleware, like logging, exception handling, etc.
• Business Logic: Executing any necessary business logic, interacting with services or databases.

Once the processing is complete, the Controller Action generates a response (such as an HTML page, JSON data, or other content). Once the response is ready, the Application Code returns to the Kestrel server.

Step 6: Kestrel Web Server

Once Kestrel receives the response, it forwards the response to the ASP.NET Core Module (ANCM).

Step 7: ASP.NET Core Module (ANCM)

Once the ASP.NET Core Module receives the response, it does not modify or process it; it simply forwards it to IIS.

Step 8: IIS

IIS receives the response from the ASP.NET Core Module (ANCM) and prepares it to be sent back to the client who initiated the request.

Step 9: Internet (Client’s Browser)

The HTTP response is sent over the internet from IIS back to the user’s browser or client application, where it can be displayed to the user.

Kestrel as an Internal Web Server:

Now, set the hosting model to OutOfProcess in the project properties file and run the application using the IIS Express profile. As shown in the image below, you will see the worker process as your project name. You can also verify in the taskbar that the IIS Server is running.

With the Out-of-Process Hosting Model, when we use IIS Express as the launch profile to run the application, IIS Express acts as the Reverse Proxy Server (Internet Facing Server), and Kestrel acts as the internal web server.

Now, IIS Express receives the incoming HTTP request and then forwards it to the Kestrel Web Server for processing. The Kestrel Web Server processes the request, generates the response, and sends it back to IIS Express, which in turn sends the response back to the client, i.e., to the browser.

What is the Role of the IIS Worker Process?

The IIS Worker Process (typically represented by w3wp.exe) acts as a reverse proxy for ASP.NET Core applications. Its primary responsibilities include:

• Handling Incoming Requests: Receives HTTP(S) requests from clients.
• Security and Authentication: IIS manages initial security tasks, such as handling SSL/TLS encryption and authentication (e.g., Windows Authentication).
• Static File Handling: If configured, IIS can directly serve static files (like HTML, CSS, JS) without needing to pass them to the ASP.NET Core application, reducing server load and improving response time.
• URL Rewriting and Routing: It can perform URL rewriting or routing based on predefined rules in the web.config file.
• Security Management: Implements various security features, such as request filtering and IP restrictions.
• Load Balancing: IIS can distribute load and manage server resources to provide reliability and scalability in production environments.

After performing these server-level tasks, the IIS Worker Process forwards the request to the Kestrel server using the ASP.NET Core Module (ANCM) for application-level processing.

What is the Role of the Kestrel Web Server Process?

The Kestrel Web Server is a cross-platform, high-performance web server for processing requests in an ASP.NET Core application. Its main functions include:

• Application Logic Execution: Once Kestrel receives the request from IIS via the ASP.NET Core Module, it starts processing the request through the application’s middleware pipeline. This pipeline handles aspects like request logging, authorization, routing, and exception handling.
• Request Processing and Response Generation: Kestrel processes routes and invokes controllers, handling the actual application logic as defined by the developer. It generates the HTTP response by setting headers, status codes, and content based on the controller’s output.
• Communication Back to IIS: After preparing the response, Kestrel sends it back through the ASP.NET Core Module to IIS, which then transmits it over the internet to the client.

In the next article, I will discuss the ASP.NET Core LaunchSettings.json file with Examples. In this article, I explain the ASP.NET Core OutOfProcess Hosting Model with examples. I hope this article will help you to understand the OutOfProcess Hosting Model in ASP.NET Core Web Applications.