Shulou(Shulou.com)06/02 Report--

This article introduces how ASP.NET 5 is achieved through XRE cross-platform, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Net programmers also have their own happiness, .NET cross-platform is a kind of happiness, .NET open source is also a kind of happiness, and even happier is to understand how .NET moves towards cross-platform step by step through open source .NET, so happiness is a process.

ASP.NET is clearly at the forefront of the cross-platform process in .NET, and you can slightly satisfy your curiosity by exploring how ASP.NET 5 implements it.

There are two ways to experience ASP.NET 5 cross-platform:

1) under Mac, git checks out the source code of XRE (formerly KRuntime), and then runs sh build.sh to complete the generation of the entire XRE project.

2) under Mac, write a simple ASP.NET project, and then run it with k kestrel. For details, see the easiest way to experience ASP.NET 5 on Mac without writing one line of code.

This blog post starts with the k command to explore the cross-platform nature of ASP.NET 5.

Run k kestrel (soon to be dotnet kestrel), and actually run 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 an OWIN Host (source code) implemented by a .NET console program, kestrel is an OWIN Server (also Web Server, source code) implemented in .NET based on libuv, and kestel is loaded by Microsoft.AspNet.Hosting.

Since Microsoft.AspNet.Hosting is a managed program, it cannot be run directly by itself. Because the prerequisite for running a .NET program is that CLR is already running, and CLR cannot run itself, CLR runs on the premise that a host program loads it.

If you have used Mono under Mac, you know that you need to use the mono command to run a .NET program. The function of the mono command is to create a process, load Mono Runtime (Mono CLR), and then execute the .NET program by Mono Runtime.

In ASP.NET 5, the mono command is not used directly, but the k command, which will also be replaced by the dotnet command since KRuntime was renamed XRE.

On non-Windows platforms, the k command corresponds to k.sh. Now when it is changed to XRE, that is, the donet command corresponds to dotnet.sh. So the secret of ASP.NET 5's cross-platform lies in dotnet.sh.

Let's go straight to 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 doubt that mono is still used. But with mono, how to load the .NET Core CLR, is it still using Mono Runtime?

With this question, look at what dotnet.mono.managed.dll has done.

The implementation code of dotnet.mono.managed.dll is in the XRE project, which is a simple C# console program that does two things: 1) analyze command line arguments; 2) call RuntimeBootstrapper.Execute ():

Public class EntryPoint {public static int Main (string [] arguments) {/ /... arguments = ExpandCommandLineArguments (arguments); / /... return RuntimeBootstrapper.Execute (arguments);}}

Continue to follow the path to [dotnet.hosting.RuntimeBootstrapper], [RuntimeBootstrapper.Execute ()] calls [RuntimeBootstrapper.ExecuteAsync ()].

The managed [RuntimeBootstrapper.ExecuteAsync ()] actually turns a corner and executes the unmanaged dotnet command (a C++ program implemented by dotnet.cpp).

The mono command (unmanaged)-> Mono Runtime-> dotnet.mono.managed (managed)-> RuntimeBootstrapper (managed)-> dotnet command (unmanaged), the code for ASP.NET 5 XRE is really eighteen bends.

After thousands of calls, she came out shyly, and the real protagonist was hidden behind the eighteen bends.

Dotnet.cpp loads 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)

Dotnet.coreclr.dll is implemented by the C++ program dotnet.coreclr.cpp in XRE, and coreclr.dll is finally loaded by dotnet.coreclr.cpp:

HCoreCLRModule =:: LoadLibraryExW (L "coreclr.dll", NULL, 0)

Dotnet.coreclr.cpp is the protagonist of loading CLR.

It doesn't make people wonder, is that okay? Just a C++ program can load CLR and execute .NET programs, so why should we install a huge. NET Framework on Windows?

I really can! An unmanaged host program + CLR, can run. Net programs, believe it or not, you can read this article shock: Hosting .NET Core Clr in your own process.

The purpose of loading CLR is to execute the IL code in the .NET assembly, and the assembly to be executed 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. CLR calls the Microsoft.AspNet.Hosting.Program.Main () method to start execution, and ASP.NET 5 gets to work.

After Core CLR is loaded and Microsoft.AspNet.Hosting is run, some related assemblies for dotnet.host continue to be loaded in RuntimeBootstrapper.ExecuteAsync () (note: this is not Core CLR, but 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"); / /.

At this point, I wonder if you have been dizzy by these eighteen bends. If you are not dizzy, please continue to look down.

At this time, a big question mark appeared, since the dotnet command can directly load Core CLR, why use the mono command to transfer?

I don't understand.

In the process of writing this blog, a bold conjecture suddenly emerged.

After Core CLR is loaded and Microsoft.AspNet.Hosting is executed, why use Mono Runtime to load some dotnet.host-related assemblies? Why not just load it with Core CLR? There is only one reason for this. Some assemblies that dotnet.host depends on are implemented in the. NET Framework, but not yet in the .NET Core Framework, while Mono is a cross-platform implementation of the .NET Framework, and there is a corresponding implementation in Mono. The full .NET Core Framework (github.com/dotnet/corefx) is still under development, and until it comes out, Microsoft can only rely on Mono. This is also the price that the cross-platform of ASP.NET has to pay. With the completion of the .NET Core Framework and the improvement of XRE, it can be expected that the cross-platform of ASP.NET will be separated from Mono.

This is the end of the sharing of ASP.NET 5's cross-platform implementation through XRE. I hope the above content can be of some help and learn more. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.