Hosting in ASP.NET Core

In this section, We will discuss about ASP.NET Core Hosting Model. The hosting model for ASP.NET Core is very different from previous versions. This is one of the key areas where majority of improvements happened in Core Model.

Once, you create any new ASP.NET Core project either via command line or via Visual Studio, it will restore all the dependencies related to server from NuGet. Below is the sample project, which I have created with Visual Studio 2017.

Now, let’s look at the package which is responsible for hosting. Microsoft.AspNetCore.Hosting, is the one which is having all the required stuffs for hosting your app. This you can also see in program.cs file.

One of the packages which you will notice is Microsoft.AspNetCore.Server.Kestrel. This includes all the stuffs hosting related including new buzzword Kestrel. If you take a closer look at the above Program class, you must be thinking that this is simple console app kind of stuff which is true basically. Upon Compilation an ASP.NET project still produces a .dll file, but with .NET Core it will launch the web server from the command line with the dotnet command line interface. However, if you are running the Visual Studio project, IIS-Express will host your app locally, the way it has been doing so far. Now, let’s look at Kestrel in a nutshell.

Kestrel is a cross-platform web server. Kestrel builds on top of libuv, a cross-platform library for asynchronous I/O. It provides Kestrel a consistent streaming API to use across Windows and Linux. You also have the option of plugging in a server based on the Windows HTTP Server API (Web Listener), or writing your own IServer implementation. Basically, you don’t want to write your own server implementation, unless you are not happy with any of the existing Kestrel stuffs. Now, let’s come to the point, why reverse proxy? Basically, IIS and other web-servers like Apache has been in use since 20+ years which means, they are robust enough to handle all the malicious HTTP-requests which are sent by different hackers. Kestrel in this space is pretty new and its job is to just deliver the content back and forth. All security related and other filtering stuffs are happened at IIS level. This also makes Kestrel very light weight and fit for the Job.

Deploying ASP.NET Core applications to IIS requires a web.config file. This is only required for IIS configuration in a reverse proxy role. A typical web.config file will look like the following. web.config file configures the ASP.NET Core Module and provides other IIS configuration. Creating, transforming, and publishing web.config is handled by Microsoft.NET.Sdk.Web, which is included when you set your project’s SDK at the top of your .csproj file, <Project Sdk="Microsoft.NET.Sdk.Web">, as shown below in the snippet.

If you don’t have a web.config file in the project when you publish with dotnet publish or with Visual Studio publish, the file is created for you in published output. If you have the file in your project, it’s transformed with the correct processPath and arguments to configure the ASP.NET Core Module and moved to published output. The transformation doesn’t touch IIS configuration settings that you’ve included in the file. In order to publish the same, I will right-click on the project and say publish like shown below. And then follow the steps as shown below. At this instant when I go to Published folder, I will see following published stuffs. Here, web.config file also got generated which will be required by IIS. Below is the sample snippet for the demo project.

The web.config file instructs IIS to send requests for all paths and verbs to a new HTTP handler named aspNetCore. 2nd part of web.config file will configure the ASP.NET Core module with instructions like how to start your application. With this change in place, now; instead of ASP.NET application running inside of a w3wp.exe, the application will execute inside of a dotnet.exe process.

Only thing which needs to be taken care while deploying the same on IIS, it should marked run under No-Managed Code in app-pool as shown below. This is because of reverse proxy and dotnet will take care of that.