“本文最初發布于 Mark Rendle 的博客，經原作者授權由 InfoQ 中文站翻譯并分享。”

筆者在Linux上安裝了.Net Core runtime，并對新的CLI、CoreRT、ASP.Net Core進行了簡單的測試與分析。

在之前文章中，我終于將整個.Net Core runtime和工具都安裝到我工作用的Linux筆記本了，包括了：

• 含 CoreCLR runtime的 ASP.NET Core 1.0-rc1
• 新的 .NET CLI

(根據命名聲明，從現在起我將會把 ASP.NET 5 寫成 ASP.NET Core)

昨晚，我開始嘗試在CoreCLR/CoreFx上運行各種當前能在Mono runtime上運行的ASP.NET Core項目。 到目前為止它們都能工作，雖然我確實將那些我認為有問題的項目留到了最后，尤其是那些使用了Azure Storage SDK中較邊緣部分的項目。:)

我在臺式機上嘗試通過那些能同時在CoreCLR和Mono的Docker容器中運行的各種服務來執行一些負載測試，我將會在這里公開那些實驗結果。

我過去的兩天里挖遍了GitHub上dotnet組織的各個倉庫之后，我所見到的讓我感到很興奮。當然，我說的不僅僅是在Linux上運行。

新的CLI

新的 dotnet CLI 與我大約在去年使用過的 dnx, dnu 和 dnvm 命令有很大差別。那些都是shell腳本（或Bash函數）；如果你執行一下 cat `which dnx` 就能看見腳本，它用Mono運行一個.Net DLL。

但如果你執行 cat `which dotnet` 你將會得到滿屏的亂碼，因為dotnet是一個本機執行文件。

我不知道現在那邊具體發展成怎樣了。在dotnet-nightly 文件夾里翻一下，有很多大小相近的本機執行文件，這挺怪異的，或許它們只是.Net程序集的裝載器，但也挺酷的。

CoreRT

由于好奇讓這一切成為可能的基礎，我進入了 CoreRT 倉庫，里面對CoreRT的描述是這樣的

一個為AOT（ahead of time compilation）場景優化的.NET Core runtime，附帶.NET Native編譯器工具鏈。

然而什么是工具鏈呢？

我找到了隱藏在文檔目錄中的intro-to-corert.md文件，其中解析了具體的情況。

這個項目的開發者（我想應該包含所有在微軟內外的貢獻者）正在構建一套工具，可以將MSIL byte-code（由Roslyn編譯C#代碼產生）預先編譯成本機x86/64機器編碼。

最初默認的實現使用新的64-bit CLR JIT編譯器（去年夏天發布）RyuJIT來產生機器編碼，但工具鏈還可以使用其他編譯器，包括它們自己引用的IL-to-C++ compiler (難以置信的小巧) and LLILC，這個是建基于LLVM的CoreCLR中正在使用的JIT編譯器，而且將來打算支持AOT編譯。

關于JIT與AOT的簡易備注

.NET CLR包含一個Just-In-Time (JIT)編譯器負責把MSIL bytecode轉換成本機機器編碼。它在你應用程序運行的時候進行轉換，而且它是在各方法第一次被調用的時候才進行轉換的；因此，“just in time”。這就是為什么同一個程序集能夠在不同的CPU和操作系統上使用。

JIT編譯器，一般來說，是優化成盡可能快地完成編譯，而不是產生盡可能好的機器編碼。

一個Ahead-Of-Time (AOT) 編譯器，能為特定的目標CPU和操作系統把所有MSIL bytecode預先轉換成本機機器編碼，所以你無需單獨的runtime就能夠分發應用或程序庫。

因為AOT編譯器不像JIT編譯器那樣有微觀時間的限制，在大部分情況下能夠產生更高效、優化度高的機器編碼。

CoreRT自身以CoreCLR和程序庫的修改版本呈現，用不同的方式進行組織，對依賴項也進行過清理。我猜測至少有些部分開啟了更高效的無用代碼刪除（dead code elimination），使其二進制文件盡可能的小。

所有這些意味著C#即將進入Go的領地 - 一個跨平臺、本地編譯、帶垃圾回收的編程語言。除此之外，C#當然擁有現代語言的特點，比如泛型、async/await等等。

本機ASP.NET Core

在同一個頁面， Roadmap的下面，有這樣的描述：

開始，我們的目標是本機可執行（又稱“控制臺程序”）。之后，我們將會把它擴展到包括ASP.NET 5程序...

而且除了當前ASP.NET Core網站應用的“XCOPY部署”模型 - 簡單地轉存一個目錄樹到服務器外，我們還可以期待“COPY部署”模型 - 僅轉存一個單獨的可執行文件。就如同一頁面所述，這會導致Dockerfile看上去像下面這樣：

FROM debian:jessieEXPOSE 5000ADD mycompiledapp.exe /  # The .exe is just there to make a point :)ENTRYPOINT /mycompiledapp

還不清楚這工具鏈是否能靜態鏈接非.NET程序庫（例如 libuv 或者 libcurl）到本機二進制文件，還是需要以動態鏈接.dll 或 .so 文件的形式一并安裝。兩種形式，都將制成十分小巧的Docker映像，而且容器的啟動也會非?？欤贿^，這一連串的想法很快引起了對 unikernels 的期待，.NET Native將來會否支持呢？

初步的答案，至少看上去是 “會。會支持的?！?/a>

這些項目明顯都在初級階段，所以沒必要太早地興奮過頭，免得將來在roadmap上有些東西會被殘忍地殺掉，但總而言之，是時候成為一個C#開發者了。

致謝：我是受Tugberk Ugurlu最近關于這方面的部落文章激發才跳入這個兔子窩的。

原文鏈接：https://blog.rendle.io/what-ive-learned-about-dotnet-native

編后語
《他山之石》是 InfoQ 中文站新推出的一個專欄,精選來自國內外技術社區和個人博客上的技術文章,讓更多的讀者朋友受益,本欄目轉載的內容都經過原作者授權。文章推薦可以發送郵件到 editors@cn.infoq.com。