In this article, we will compare InProcess and OutOfProcess hosting models in ASP.NET Core and learn more about each hosting model.
Hosting refers to deploying an application into the server for external access. Understanding the hosting process is essential in implementing a reliable deployment setup.
Let’s dive into each one of the hosting models.
InProcess Hosting
Before ASP.NET Core 2.2, the only option to host the application was the OutOfProcess model. This model uses an external server proxying the request to an internal server that hosts the application. We will learn more about the OutOfProcess model in our next section.
The InProcess hosting model is available from ASP.NET Core 2.2 onwards. With this model, we host the application directly inside the IIS worker process(w3wp.exe). We can avoid using the reverse proxy server, as IIS manages the end-to-end application hosting process.
Also note that, during the development, we may use IIS Express for hosting applications locally. The worker process name of IIS Express is iisexpress.exe.
Pipeline of InProcess Hosting
Let’s now look at how InProcess hosting works:
When an HTTP request hits the IIS, the ASP.NET Core Module receives the native HTTP request. The ASP.NET Core module is a native IIS module part of the IIS pipeline responsible for receiving native HTTP requests. Further, the IIS HTTP Server receives the native request and converts it into a managed request acceptable for the ASP.NET Core Middleware pipeline.
Afterward, the ASP.NET Core Middleware pipeline processes the request and passes it on as an HttpContext instance. Finally, the application code runs using the HttpContext instance.
In the response generation stage, the application code creates the response and passes it to the IIS. The IIS sends the response back to the client that sent the request.
Experimentation With Code
How about we experiment and find out which process runs our application code?
For this, let’s create a Web API project and modify the Program.cs file to add a middleware:
app.Run(async context => await context.Response.WriteAsync(Process.GetCurrentProcess().ProcessName));
Here, we create a terminal middleware delegate to the app’s request pipeline using the app.Run() method. We use the System.Diagnostics.Process class to retrieve the current process that runs our application and then write the process name to the HttpContext response stream using the WriteAsync() method of HttpResponse class.
If we select IIS or IISExpress and run the application, we will see that the output prints the corresponding process that executes the application. That is, either w3wp or iisexpress.
From ASP.NET Core 3.0 onwards, the in-process hosting model is the default. Although, we can explicitly specify the hosting model by modifying the project file and setting the AspNetCoreHostingModel property:
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
If we rerun the application after setting the hosting model explicitly, the output should still be the same.
OutOfProcess Hosting
Before ASP.NET Core 2.2, OutOfProcess was the only hosting model available. With OutOfProcess hosting, the application runs on a separate process from the one provided by IIS. The process that hosts the app is dotnet.exe.
In OutOfProcess hosting, we use two web servers: an internal and a reverse proxy server. The internal web server is the Kestrel server, and IIS is the reverse proxy server.
We can also implement OutOfProcess hosting without a reverse proxy server by configuring Kestrel. With this, the Kestrel server itself is the internet-facing server.
Let’s now look at these two implementations.
The Pipeline of OutOfProcess Hosting With a Reverse Proxy Server
First, we’ll look at how the OutOfProcess hosting pipeline works with a reverse proxy server:
With this hosting model, we use IIS as a reverse proxy server. This is useful in case we need to take advantage of some of the unique features IIS supports but Kestrel doesn’t (Eg. Windows authentication).
Here, the IIS forwards the HTTP request to the Kestrel server, which transfers the request to the middleware pipeline. The middleware pipeline handles the request and passes it on as an HttpContext instance to the app’s logic.
The Pipeline of OutOfProcess Hosting Without a Reverse Proxy Server
We will now see how OutOfProcess hosting pipeline works without using a reverse proxy server:
In this case, the Kestrel server acts as the main application server. This means that the Kestrel server is the internet-facing server that handles incoming requests directly.
Note that if we run the application via .NET core CLI, it ignores the AspNetCoreHostingModel set in the project file and uses the OutOfProcess hosting model by default.
Experimentation With Code
Let’s use the same project we created and update the project file to use the OutOfProcess hosting model:
<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel> <UseAppHost>False</UseAppHost>
The AspNetCoreHostingModel setting specifies the hosting model to use.
We then set the UseAppHost setting to false to disable the generation of a native executable. If we don’t do that, the build generates an executable file with the name of the project file, and the application runs within that executable. Using this setting, ensure the application uses the dotnet.exe process for hosting.
Once we run the application, we should see the output as dotnet.
InProcess Vs OutOfProcess Hosting
The InProcess hosting doesn’t use a reverse proxy server. This avoids the connection setup between IIS and Kestrel. That means the requests are not proxied over the loopback adapter, a network interface that returns outgoing network traffic to the same machine.
The advantage of the Kestrel server is its platform independence. Due to this, for hosting applications on multiple platforms, Kestrel comes in handy. In this case, we could prefer OutOfProcess hosting with Kestrel. Also, when we are hosting smaller APIs that either don’t have an IIS setup and don’t need IIS features like Windows authentication or FTP, we could opt for OutOfProcess hosting.
Also, with OutOfProcess hosting, using Kestrel alone may not provide all the required functionalities. This is because Kestrel is a lightweight server and doesn’t provide extensive options for configuration. This includes:
- Windows Authentication does not exist on Kestrel as it’s cross-platform
- Request Filtering is not available out of the box with Kestrel
- Kestrel doesn’t support multiple apps on the same port
This is also one of the reasons why we opt for InProcess hosting.
Conclusion
In this article, we’ve learned about the InProcess and OutOfProcess hosting models available in ASP.NET Core. We also understood the processing pipeline of both models and understood the differences between them.
As we have discussed, although both InProcess and OutOfProcess hosting models have their use cases, the in-process hosting model provides better performance. This is why ASP.NET uses InProcess hosting by default.
