Monthly Archives: April 2015

An Inside Look at ASP.NET 5 Execution – Part I

Posted on by
Reply

In this series of posts I’ll try to track what’s happening inside .NET Core and ASP.NET (open source FTW!) from the moment we run “k web” on a command line to the moment the application returns an HTTP response. I’ll use the simple “hello world” application from previous posts and ASP.NET 5 beta 3. Note that some things were renamed meanwhile, namely KRE which is now DNX (.NET execution environment) and its command line tools.

Before going into the rust I’d like to highlight two things. The first, is that project dependencies are now on steroids. A dependency defined within a project.json file can be resolved by different means, namely from a NuGet package or the corresponding project source. You can create a global.json file at solution level which allows you to specify the folders that contain source code (projects). If a project that matches a dependency is found on any of these folders, it is used instead of the corresponding NuGet package. In addition, Visual Studio will also load those projects and allow you to easily navigate on the source. This is perfect to debug the framework itself and take a look at what’s going on! Here’s what I did:

  • Clone the Hosting, Http Abstractions, MVC and DNX repos from GitHub to some local folder.
  • Checkout the 1.0.0-beta3 tag (6.0.0-beta3 for MVC).
  • Add the source folders on each repo to my global.json file.
{
    "sources": [
        "src",
        "C:/aspnet-source/hosting/src",
        "C:/aspnet-source/http-abstractions/src",
        "C:/aspnet-source/mvc/src"        
    ],
    "sdk": {
        "version": "1.0.0-beta3"
    }
}
  • Run VS and wait until everything is loaded..

vs_solution

The second thing to point out is that running “k web” on the command line is actually equivalent to:

klr --appbase . Microsoft.Framework.ApplicationHost web

Which in turn is equivalent to passing the command definition inline (from project.json):

klr --appbase . Microsoft.Framework.ApplicationHost Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5000

This is a good time to recap the DNX Runtime structure. We’re invoking klr.exe which is “a very thin layer with the responsibility to find and call the native CLR host, passing along arguments given to the process to be used by the rest of the stack”. The selected native CLR host will be specific to the version of the CLR that is being used and it is responsible for invoking the managed entry point, which in turn invokes the generic application host (Microsoft.Framework.ApplicationHost). Among other base services, the application host layer includes support for the project.json structure, namely gathering and resolving dependencies (e.g. NuGet packages, project references).

The DNX application host invokes the “application” (assembly) that is passed as the following argument on the command line, which in this case is ASP.NET’s hosting layer (we’re situated on layer 4 of the DNX structure diagram). This last layer is responsible for finding the Web server to run on and bootstrapping the Web application. Note that the last command line arguments are only used at this point.

This should cover enough to get us started. On the next post I’ll go into the code that executes when running “k web”, starting on the DNX application host.

Advertisement