Unstoppable curiosity: asp.net 5 is how to implement Cross-platform through Xre

. NET programmers have their own happiness, too. NET Cross-platform is a kind of happiness. NET open source is also a kind of happiness, and more happy can be through open source. NET understand how. NET is moving toward cross-platform, so happiness is a process.

In the. NET Cross-platform process, ASP. NET is clearly ahead, and by exploring how ASP.net 5 is cross-platform, you can slightly satisfy your curiosity.

Experience asp.net 5 cross-platform There are 2 different ways:

1 under the Mac, Git checks out the Xre source code (formerly known as Kruntime), then runs the SH build.sh, can complete the entire Xre project generation.

2 under the Mac, write a simple ASP.net project, and then run with K Kestrel, see not write 1 lines of code, experience on the Mac asp.net 5 the easiest way.

This blog post from the K command, a probe into the ASP.net 5 across the platform.

Run K Kestrel (soon to be dotnet Kestrel), which is actually running the following command (according to the commands configuration in Project.json):

K "Microsoft.AspNet.Hosting--server Kestrel--server.urls http://localhost:8002"

Microsoft.AspNet.Hosting is a. NET console program implementation of the Owin Host (source), Kestrel is a libuv based. NET implementation of the Owin server (also Web server, source code), Kestel is loaded by Microsoft.AspNet.Hosting.

Since Microsoft.AspNet.Hosting is a managed program, it cannot be run directly by itself. Because running one. NET program if the CLR is already running and the CLR itself cannot run itself, the CLR is running with a host program loading it.

If you've used mono under a Mac, you'll know to run one. NET programs need to use the Mono command, the Mono command is to create a process, load the Mono Runtime (Mono CLR), and then execute the. NET program by Mono Runtime.

And in ASP.net 5, and not directly with the Mono command, but K command, since Kruntime renamed Xre, the K command will also be replaced by the dotnet command.

On non-Windows platforms, the K command corresponds to k.sh. Now change to Xre, that is, the donet command corresponds to dotnet.sh. So the secret of ASP.net 5 across the platform is hidden in dotnet.sh.

The following is a direct hit on the scripts/dotnet.sh in the Xre project:

#...
If [f "$DIR/mono"]; Then
  exec "$DIR/mono" $MONO _options "$DIR/dotnet.mono.managed.dll" "$@"
else
  exec mono $MONO _options "$ Dir/dotnet.mono.managed.dll "" $@ "
fi

There is no suspense, still using the mono. But with mono, how do you load the. NET Core CLR, or do you use mono Runtime?

With this doubt, the clues to see what dotnet.mono.managed.dll dry.

The Dotnet.mono.managed.dll implementation code, in the Xre project, is a simple C # console program that does two things: 1 parse command-line arguments; 2 Invoke Runtimebootstrapper.execute ():

public class entrypoint
{public
    static int Main (string[] arguments)
    {
        //...
        arguments = expandcommandlinearguments (arguments);
        //...
        return Runtimebootstrapper.execute (arguments);
    }

Continue to follow through [Dotnet.hosting.runtimebootstrapper],[runtimebootstrapper.execute ()] called [ Runtimebootstrapper.executeasync ()].

The managed [Runtimebootstrapper.executeasync ()] turned a corner and executed the unmanaged dotnet command (a C + + program implemented by Dotnet.cpp).

Mono command (unmanaged)-> Mono Runtime-> dotnet.mono.managed (Managed)-> Runtimebootstrapper (Managed)-> dotnet Command (unmanaged), ASP.net 5 Xre's code is 18 bends.

Long-awaited began to come out, the original real protagonist is hidden in the 18 after the bend.

The dotnet.cpp loaded the unmanaged Dotnet.coreclr.dll:

LPCWSTR Pwzhostmodulename = L "Dotnet.coreclr.dll";

M_hhostmodule =:: Loadlibraryexw (Pwzhostmodulename, NULL, load_library_search_default_dirs);

Pfncallapplicationmain = (fncallapplicationmain):: GetProcAddress (M_hhostmodule, pszcallapplicationmainname);

And Dotnet.coreclr.dll is implemented by the C + + program in Xre, and finally by Dotnet.coreclr.cpp loaded Coreclr.dll:

Hcoreclrmodule =:: Loadlibraryexw (L "Coreclr.dll", NULL, 0);

Dotnet.coreclr.cpp is the main character that loads the CLR.

It's not a question, can it? Only one C + + program can load the CLR, execute. NET program, why do we have to install a large. NET Framework on Windows?

I can do that! An unmanaged host program +CLR, it can run. NET program, do not believe you can read this article shook: Hosting. NET Core CLR in your own process.

The purpose of loading the CLR is to execute the IL code in a. NET assembly, and the Assembly to execute is passed by the command-line arguments of the dotnet command (formerly the K command), such as Dotnet Kestrel (formerly K Kestrel), and the corresponding assembly is Microsoft.AspNet.Hosting. The CLR calls the Microsoft.AspNet.Hosting.Program.Main () method to begin execution, and ASP.net 5 begins to work.

After the Core CLR is loaded and the Microsoft.AspNet.Hosting is run, in Runtimebootstrapper.executeasync (), Also continues to load some Dotnet.host related assemblies (note: This is not the core CLR, but the mono Runtime).

//...
var assembly = Assembly.Load (New AssemblyName ("Dotnet.host"));
//...
var loadercontainertype = assembly. GetType ("Dotnet.host.LoaderContainer");
var cachedassemblyloadertype = assembly. GetType ("Dotnet.host.CachedAssemblyLoader");
var pathbasedloadertype = assembly. GetType ("Dotnet.host.PathBasedAssemblyLoader");
//...

Here, I do not know if you have been this 18 bend to Halo, if not be around dizzy, please continue to look down.

At this time a big question mark emerges in front of, since dotnet command can load the core CLR directly, why also use mono command to relay?

Puzzled by the solution ...

In the course of writing this blog post, a bold conjecture was suddenly created-

Why do I have to load some dotnet.host-related assemblies with mono runtime after the core CLR is loaded and the Microsoft.AspNet.Hosting is executed? Why not just load it with the core CLR? This can only be explained by one reason, some of the Dotnet.host dependencies are implemented in the. NET Framework, but not yet implemented in the. NET Core framework, and Mono is a cross-platform implementation of the. NET Framework. There are also corresponding implementations in the mono. The complete. NET Core Framework (GITHUB.COM/DOTNET/COREFX) is still under intense development, and Microsoft can only use mono before it comes out. This is also the asp.net of the platform to pay the price, with the completion of the. NET Core Framework, xre improvements, you can expect ASP.net cross-platform will be out of mono.

Of course, this is just a conjecture, if you know the truth, welcome to uncover.