擋不住的好奇心：ASP.NET 5是如何通過XRE實現跨平臺的 - dudu－IT工程師數位筆記本

文章出處

好奇號火星車

.NET程序員也有自己的幸福，.NET的跨平臺是一種幸福，.NET的開源也是一種幸福，而更幸福的是可以通過開源的.NET了解.NET是如何一步步走向跨平臺的，所以幸福是一種過程。

在.NET跨平臺的進程中，ASP.NET顯然走在了前頭，而通過探究ASP.NET 5是如何實現跨平臺的，可以稍稍滿足一下自己的好奇心。

體驗ASP.NET 5跨平臺有2種方式：

1）在Mac下，git簽出XRE的源代碼（前身是KRuntime），然后運行sh build.sh，就能完成整個XRE項目的生成。

2）在Mac下，寫一個簡單的ASP.NET項目，然后用k kestrel運行，詳見不寫1行代碼，在Mac上體驗ASP.NET 5的最簡單方法。

這篇博文就從k命令下手，一探ASP.NET 5跨平臺的究竟。

運行k kestrel（即將是dotnet kestrel），實際運行的是下面的命令（根據project.json中的commands配置）：

k "Microsoft.AspNet.Hosting --server kestrel --server.urls http://localhost:8002"

Microsoft.AspNet.Hosting是一個.NET控制臺程序實現的OWIN Host（源碼），kestrel是一個基于libuv用.NET實現的OWIN Server（也是Web Server，源碼），kestel是由Microsoft.AspNet.Hosting加載的。

既然Microsoft.AspNet.Hosting是一個托管程序，它自己是無法直接運行的。因為運行一個.NET程序的前提條件是CLR已運行，而CLR自己不能運行自己，CLR運行的前提是有一個host程序將它加載。

如果你在Mac下用過Mono，就你就知道運行一個.NET程序需要用mono命令，mono命令的作用就是創建一個進程，加載Mono Runtime(Mono CLR)，然后由Mono Runtime執行.NET程序。

而在ASP.NET 5中，并沒有直接用mono命令，而是k命令，自從KRuntime改名為XRE之后，k命令也將會被dotnet命令取代。

dotnet.sh

在非Windows平臺下，k命令對應的是k.sh。現在改為XRE之后，也就是donet命令對應dotnet.sh。所以ASP.NET 5跨平臺的秘密就藏在dotnet.sh中。

下面就直擊XRE項目中的scripts/dotnet.sh：

#...
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

毫無懸念，依然用的是mono。但是用了mono，如何加載.NET Core CLR，難道還是用Mono Runtime？

帶著這個疑問，順藤摸瓜，看dotnet.mono.managed.dll干了啥。

dotnet.mono.managed.dll的實現代碼就在XRE項目中，是一個簡單的C#控制臺程序，它干了兩件事：1）分析命令行參數；2）調用RuntimeBootstrapper.Execute()：

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

繼續順藤摸瓜至 [dotnet.hosting.RuntimeBootstrapper]，[RuntimeBootstrapper.Execute()] 調用了 [RuntimeBootstrapper.ExecuteAsync()]。

而托管的 [RuntimeBootstrapper.ExecuteAsync()] 竟然拐了個彎，執行了非托管的dotnet命令（一個由dotnet.cpp實現的C++程序）。

mono命令(非托管) -> Mono Runtime -> dotnet.mono.managed(托管) -> RuntimeBootstrapper(托管) -> dotnet命令(非托管)，ASP.NET 5 XRE的代碼真是十八彎。

千呼萬喚始出來，原來真正的主角就藏在十八彎之后。

dotnet.cpp加載了非托管的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是由XRE中的C++程序dotnet.coreclr.cpp實現的，最終由dotnet.coreclr.cpp加載了coreclr.dll：

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

dotnet.coreclr.cpp就是加載CLR的主角。

這不讓人產生疑問，這也可以？僅靠一個C++程序就能加載CLR，執行.NET程序，那我們在Windows上為什么要安裝一個龐大的.NET Framework？

真的可以！一個非托管的host程序+CLR，就能運行.NET程序，不信你可以看這篇文章震撼一下：Hosting .NET Core Clr in your own process 。

加載CLR的目的是為了執行.NET程序集中的IL代碼，而要執行的程序集是由dotnet命令（前身是k命令）的命令行參數所傳遞過來的，比如dotnet kestrel（之前是k kestrel），對應的程序集是 Microsoft.AspNet.Hosting。CLR調用 Microsoft.AspNet.Hosting.Program.Main() 方法開始執行，ASP.NET 5就開始干活了。

Core CLR被加載、Microsoft.AspNet.Hosting被運行之后，在 RuntimeBootstrapper.ExecuteAsync() 中，還繼續加載了一些dotnet.host的相關程序集（注意：這時不是Core CLR，而是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");
//...

到這里，不知你有沒有被這十八彎給繞暈，如果沒被繞暈，請繼續往下看。

這時一個大大的問號浮現在眼前，既然dotnet命令能直接加載Core CLR，為什么還要用mono命令中轉一下？

百思不得其解。。。

在寫這篇博文的過程中，突然產生了一個大膽猜想——

在Core CLR被加載，Microsoft.AspNet.Hosting被執行之后，為什么還要用Mono Runtime加載一些dotnet.host相關的程序集？為什么不直接用Core CLR加載呢？這只能用一個原因來解釋，dotnet.host依賴的一些程序集在在.NET Framework中有實現，但是在.NET Core Framework中還沒有實現，而Mono是.NET Framework的一個跨平臺實現，在Mono中也有對應的實現。完整的.NET Core Framework（github.com/dotnet/corefx）還在緊張開發之中，在它出來之前，微軟只能借助Mono。這也是ASP.NET的跨平臺走在前面要付出的代價，隨著.NET Core Framework的完成，XRE的改進，可以預計ASP.NET的跨平臺是會脫離Mono的。

當然，這只是一個猜想，如果你知道真相，歡迎來揭開。

文章列表