.NET程序員也有自己的幸福，.NET的跨平臺是一種幸福，.NET的開源也是一種幸福，而更幸福的是可以通過開源的.NET了解.NET是如何一步步走向跨平臺的，所以幸福是一種過程。
在.NET跨平臺的進程中，ASP.NET顯然走在了前頭，而通過探究ASP.NET 5是如何實現(xiàn)跨平臺的，可以稍稍滿足一下自己的好奇心。
體驗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），實際運行的是下面的命令（根據(jù)project.json中的commands配置）：
k "Microsoft.AspNet.Hosting --server kestrel --server.urls http://localhost:8002"
Microsoft.AspNet.Hosting是一個.NET控制臺程序?qū)崿F(xiàn)的OWIN Host（源碼），kestrel是一個基于libuv用.NET實現(xiàn)的OWIN Server（也是Web Server，源碼），kestel是由Microsoft.AspNet.Hosting加載的。
既然Microsoft.AspNet.Hosting是一個托管程序，它自己是無法直接運行的。因為運行一個.NET程序的前提條件是CLR已運行，而CLR自己不能運行自己，CLR運行的前提是有一個host程序?qū)⑺虞d。
如果你在Mac下用過Mono，就你就知道運行一個.NET程序需要用mono命令，mono命令的作用就是創(chuàng)建一個進程，加載Mono Runtime(Mono CLR)，然后由Mono Runtime執(zhí)行.NET程序。
而在ASP.NET 5中，并沒有直接用mono命令，而是k命令，自從KRuntime改名為XRE之后，k命令也將會被dotnet命令取代。
在非Windows平臺下，k命令對應的是k.sh?，F(xiàn)在改為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的實現(xiàn)代碼就在XRE項目中，是一個簡單的C#控制臺程序，它干了兩件事：1）分析命令行參數(shù)；2）調(diào)用RuntimeBootstrapper.Execute()：
public class EntryPoint{ public static int Main(string[] arguments) { //... arguments = ExpandCommandLineArguments(arguments); //... return RuntimeBootstrapper.Execute(arguments); }}
繼續(xù)順藤摸瓜至 [dotnet.hosting.RuntimeBootstrapper]，[RuntimeBootstrapper.Execute()] 調(diào)用了 [RuntimeBootstrapper.ExecuteAsync()]。
而托管的 [RuntimeBootstrapper.ExecuteAsync()] 竟然拐了個彎，執(zhí)行了非托管的dotnet命令（一個由dotnet.cpp實現(xiàn)的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實現(xiàn)的，最終由dotnet.coreclr.cpp加載了coreclr.dll：
hCoreCLRModule = ::LoadLibraryExW(L"coreclr.dll", NULL, 0);
dotnet.coreclr.cpp就是加載CLR的主角。
這不讓人產(chǎn)生疑問，這也可以？僅靠一個C++程序就能加載CLR，執(zhí)行.NET程序，那我們在Windows上為什么要安裝一個龐大的.NET Framework？
真的可以！一個非托管的host程序+CLR，就能運行.NET程序，不信你可以看這篇文章震撼一下：Hosting .NET Core Clr in your own process 。
加載CLR的目的是為了執(zhí)行.NET程序集中的IL代碼，而要執(zhí)行的程序集是由dotnet命令（前身是k命令）的命令行參數(shù)所傳遞過來的，比如dotnet kestrel（之前是k kestrel），對應的程序集是 Microsoft.AspNet.Hosting。CLR調(diào)用 Microsoft.AspNet.Hosting.Program.Main() 方法開始執(zhí)行，ASP.NET 5就開始干活了。
Core CLR被加載、Microsoft.AspNet.Hosting被運行之后，在 RuntimeBootstrapper.ExecuteAsync() 中，還繼續(xù)加載了一些dotnet.host的相關(guān)程序集（注意：這時不是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");//...
到這里，不知你有沒有被這十八彎給繞暈，如果沒被繞暈，請繼續(xù)往下看。
這時一個大大的問號浮現(xiàn)在眼前，既然dotnet命令能直接加載Core CLR，為什么還要用mono命令中轉(zhuǎn)一下？
百思不得其解。。。
在寫這篇博文的過程中，突然產(chǎn)生了一個大膽猜想——
在Core CLR被加載，Microsoft.AspNet.Hosting被執(zhí)行之后，為什么還要用Mono Runtime加載一些dotnet.host相關(guān)的程序集？為什么不直接用Core CLR加載呢？這只能用一個原因來解釋，dotnet.host依賴的一些程序集在在.NET Framework中有實現(xiàn)，但是在.NET Core Framework中還沒有實現(xiàn)，而Mono是.NET Framework的一個跨平臺實現(xiàn)，在Mono中也有對應的實現(xiàn)。完整的.NET Core Framework（github.com/dotnet/corefx）還在緊張開發(fā)之中，在它出來之前，微軟只能借助Mono。這也是ASP.NET的跨平臺走在前面要付出的代價，隨著.NET Core Framework的完成，XRE的改進，可以預計ASP.NET的跨平臺是會脫離Mono的。
當然，這只是一個猜想，如果你知道真相，歡迎來揭開。
【編輯推薦】
