IIS (Internet Information Services) is the web server on Windows that handles incoming HTTP requests. ASP.NET Core applications do not run directly inside IIS — they run on their own server called Kestrel.
The bridge between IIS and ASP.NET Core is built by the ASP.NET Core Module (ANCM). This module receives incoming requests and forwards them to the application. But exactly how it forwards them depends on the hosting model.
Think of a factory. The manager works directly on the production line — same space, same team. Fast communication, minimal delay.
In inprocess mode, the ASP.NET Core application runs inside IIS's worker process, w3wp.exe. There is no extra communication layer in between. That is why it is faster.
But there is a risk: if w3wp.exe crashes, all applications running inside that same process crash together.
In the same factory, the manager now works in a separate room. Messages come from the production line, the manager processes them in their own room, and sends back the response.
In outofprocess mode, the ASP.NET Core application runs in its own dotnet.exe process, independent from IIS. IIS only acts as a middleman — it receives the request, forwards it to Kestrel, and sends back the response.
The advantage: if one application crashes, the others are not affected. Each application lives in its own isolated process.
Both have their use cases. Instead of blindly picking one, the decision should be based on context.
The hosting model is determined by the hostingModel attribute in the web.config file. Checking this value after publishing is a good habit.
<!-- inprocess: uygulama IIS worker process (w3wp.exe) içinde çalışır -->
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout"
hostingModel="inprocess" />
<!-- outofprocess: uygulama kendi dotnet.exe process'inde çalışır -->
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout"
hostingModel="outofprocess" />