Kestrel Web Server in ASP.NET Core

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

Kestrel Web Server in ASP.NET Core Application

In this article, I will discuss the Kestrel Web Server in ASP.NET Core Application with Examples. Please read our previous article discussing the ASP.NET Core InProcess Hosting Model with Examples. 

What is Kestrel Web Server?

As we already discussed, ASP.NET Core is a Cross-Platform framework. It supports developing and running applications on multiple operating systems, such as Windows, Linux, or MacOS. Microsoft developed the Kestrel web server as the default Cross-Platform Web Server for hosting the ASP.NET Core Web Application on Windows, Linux, and MacOS. Kestrel is designed to be lightweight, fast, and efficient, making it suitable for both development and production environments.

What is the Process Name for the Kestrel Web Server?

In ASP.NET Core, the application code executes within the Kestrel server’s worker process when using the Kestrel web server. The process name depends on how the application is deployed:

Self-Contained Deployment:

When an ASP.NET Core application is published as self-contained, it includes the .NET runtime, meaning it does not require the .NET runtime to be pre-installed on the host machine. This deployment type generates an executable file specific to the application (e.g., FirstCoreWebApplication.exe on Windows or FirstCoreWebApplication on Linux/macOS).

The resulting executable file (e.g., FirstCoreWebApplication.exe) runs as its own process. Therefore, the process name will be the name of the application’s executable file without the extension. For example:

• Application Name: FirstCoreWebApplication
• Process Name: FirstCoreWebApplication

Note: With a self-contained deployment, the application runs independently, which provides greater portability but results in a larger deployment size since it bundles the .NET runtime with the application.

Framework-Dependent Deployment:

When we publish the application as framework-dependent, it relies on a shared .NET runtime installed on the host machine. In this case, the application runs through the dotnet executable. The process name in this scenario will be dotnet.exe (on Windows) or dotnet (on Linux/macOS), with the application loaded as a module within this process. For example:

• Application Name: FirstCoreWebApplication
• Process Name: dotnet.exe (on Windows) or dotnet (on Linux/macOS)

Note: A framework-dependent deployment produces a smaller deployment package but requires the target machine to have the correct .NET runtime installed. Only our application and its dependencies are deployed, resulting in a smaller deployment size.

How Do We Run Applications Using Kestrel Web Server in ASP.NET Core?

Before using the Kestrel Web Server to host and run our ASP.NET Core application, let us first open the launchSettings.json file inside the Properties folder. Once you open the launchSettings.json file, you will find the following code by default.

{
  "$schema": "http://json.schemastore.org/launchsettings.json",
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:16145",
      "sslPort": 44335
    }
  },
  "profiles": {
    "http": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "http://localhost:5051",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "https": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "https://localhost:7084;http://localhost:5051",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

Note: In our example, for IIS Express, the port number is 16145 for HTTP and 44335 for HTTP, and the worker process will be express. On the other hand, for the Kestrel Server (command name Project), the port number is 5051 for HTTP and 7084 for HTTPS, and the worker process name will be FirstCoreWebApplication (it is nothing but the executable file name).

In our upcoming session, we will discuss launchSettings.json in detail. But for now, have a look at the Lunch Profiles section. Here, you can see four options, as shown in the image below.

IIS Express Profile:

• IIS Express is a lightweight, self-contained version of Internet Information Services (IIS) designed for development. By default, it hosts ASP.NET Core applications in-process, meaning the application runs within the same IIS Express worker process (iisexpress.exe).
• IIS Express supports both HTTP and HTTPS connections, with URLs and ports specified in launchSettings.json.
• IIS Express simulates a full IIS environment, making it ideal for testing applications in a development setup close to production IIS hosting.

HTTP and HTTPS Profile:

• HTTP and HTTPS Profiles use Kestrel Web Server, a cross-platform, high-performance web server developed for ASP.NET Core. The application runs directly in the Kestrel Web Server Worker process.
• The launch profile in launchSettings.json can configure Kestrel to listen to specific HTTP or HTTPS URLs and ports.
• Kestrel is well-suited for cross-platform development and testing. It mirrors production environments commonly used for Linux or non-IIS deployments, such as when Kestrel is used standalone or behind a reverse proxy like Nginx or Apache.

WSL Profile (Windows Subsystem for Linux):

• When running the application under the Windows Subsystem for Linux (WSL), the application uses Kestrel. It runs as if on a Linux environment, Linux-compatible system libraries, paths, and command-line tools.
• ASP.NET Core applications can be launched within WSL to simulate a Linux environment on Windows, with configurations specified in launchSettings.json.
• WSL is useful for developers preparing applications for Linux production environments. Testing in WSL can help catch Linux-specific issues and ensure compatibility before deploying to Linux servers.

Example to Understand Kestrel Web Server in ASP.NET Core:

To display the name of the process that executes our application code in the browser, we need to use System.Diagnostics.Process.GetCurrentProcess().ProcessName within the Main method of the Program class. So, please modify the Program class as follows:

namespace FirstCoreWebApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);
            var app = builder.Build();

            app.MapGet("/", () => "Worker Process Name : " + System.Diagnostics.Process.GetCurrentProcess().ProcessName);

            app.Run();
        }
    }
}

Running the Application:

Now, run the application using the IIS Express Profile. It will use the URL and Port Number mentioned in the iisSettings of your launchSettings.json file. To prove this, run the application using IIS Express and see the output shown below.

Running the Application using Kestrel Server:

To use the Kestrel Web Server to host and run our application in Visual Studio, we need to run the application using either HTTP or HTTPS Profiles. Let’s run the application using the HTTP profile. Once you run the application using the HTTP profile, you need to observe two things.

First Thing:

First, it will launch the command prompt and host the application using the Kestrel Web Server, as shown in the image below. Here, you need to focus on the URL and Port Number, which should be the same as those mentioned in the HTTP profile of the launchSettings.json file.

Second Thing:

Secondly, it opens the default web browser and listens to that URL and Port Number, which uses the HTTPS protocol, as shown in the image below.

You can also verify whether it is using the Kestrel Web Server by using the browser developer tool. Run the application and open the browser developer tool by pressing the F12 key. Then go to the Network tab and refresh the page. You should see that it shows Kestrel as the server, as shown in the image below.

Note: In our example, Kestrel is the only Web Server hosting our ASP.NET Core Web Application and Handling the incoming HTTP Requests. We don’t need to install the Kestrel Web Server separately. It is included by default in ASP.NET Core, and this Kestrel Web Server makes ASP.NET Core cross-platform.

What Hosting Model does the Kestrel Server use when handling the Request alone?

When Kestrel is used independently, meaning it directly handles incoming HTTP/HTTPS requests without a reverse proxy (like IIS, Apache, or Nginx), the terms InProcess and OutOfProcess do not apply.

Next=> Once we understand the In-Process Hosting Model and Kestrel Web Server, we need to understand the Out-of-Process Hosting Model using an ASP.NET Core Web Application.

In the next article, I will discuss the ASP.NET Core OutOfProcess Hosting Model with Examples. In this article, I try to explain the Kestrel Web Server in an ASP.NET Core Web Application with Examples. I hope this article will help you understand the Kestrel Web Server in an ASP.NET Core Web Application.