在上一篇文章《使用.NET Core快速開發一個較正規的命令行應用程序》中我們看到了使用自包含方式發布的.NET Core應用中包含了216個文件。我就寫一個cat命令用得着這么動真格。。。這寫出來的命令行還有人用嗎？今天我們就來介紹一下MS的另一個開源項目CoreRT。用來解決這個棘手的問題。
什么是CoreRT？
CoreRT 是MS一個長期開源項目，它早在一年前就已經建立了，持續到今。
項目目標
將.NET Core托管（CLR）應用程序編譯為本地（特地平台）的單一可執行文件。
說白了就是將.NET Core編譯為機器碼（也可以是其他東西，如C++代碼），而不再有之前的運行時，將.NET變為真正的“靜態編譯形”語言。
基本信息
項目地址：https://github.com/dotnet/corert
支持的平台
- Windows x64
- MacOS x64
- Linux x64/ARM
- CppCodeGen
- WebAssembly（Blazor目前還是基於Mono的，如果CoreRT成型，不出意外會切換到CoreRT）
可以看到目前沒有支持x86，所以想跑在x86架構的平台上還是老老實實的吧。。
項目狀態
目前項目版本是：alpha，也就是說非正式版，切還離得比較遠。
所以不推薦大家用在比較大型或商業項目上，會出很多問題。
但寫個小程序，小工具還是沒什么太大問題的。
Native的優勢是什么？
Native的優勢我一說到就激動，期待了很久。從早期Core beta2還有這個功能，到后面被擱置（來不及發布）經歷了期望與失落。。克制住情緒，下面我們來理性分析一下Native的好處。
更少的發布文件
Native后發布文件明顯減少，一般情況下我們的.NET應用，每引用一個packages就至少增加一個文件（*.dll）Native會將這些dll都打包在一起。這樣極大方便了發布和部署。
啟動速度更快
我們都知道托管語言（.NET、Java）第一次執行（不僅僅是啟動，所有的方法、語句第一次執行都一樣）都很慢（《在.net中為什么第一次執行會慢？》），這是托管語言的優勢也同樣是劣勢。
Native后就不存在虛擬機技術（CLR、JVM）也就沒有的即時編譯這個動作了。得到的好處就是第一次執行跟第二次執行是一樣的。
更少的內存資源
Native后會進一步減少內存的使用，不需要加載一些核心“框架”（JIT）等。
Native的缺點？
Native並不是萬能的，也存在缺點。但我覺得整體上利大於弊。
更強的針對性
Native后就基本不能跨平台了（這邊的跨平台是指一次發布到處運行，並不是指程序不能跨平台）
也就是說，如果你要運行在windows上需要單獨為windows進行一次發布，運行在MacOS上也需要單獨進行一次發布，運行在Linux上同樣也需要單獨進行一次發布（當然還包括x86\x64\ARM這樣的變更，都需要重新發布）
同樣JIT也無法為代碼提供執行編譯優化，可以參考之前文章中，關於CPU個數的代碼優化。
使用CoreRT發布你的第一個Native應用程序
添加Packages
首先，因為這個項目還沒有正式發布，所以你需要添加dotnet團隊的每日構建nuget源，地址為：https://dotnet.myget.org/F/dotnet-core/api/v3/index.json
然后安裝packages：Microsoft.DotNet.ILCompiler
或者你可以在你的項目路徑下執行下面的命令：
dotnet add package Microsoft.DotNet.ILCompiler -s https://dotnet.myget.org/F/dotnet-core/api/v3/index.json –v 1.0.0-alpha-*
設置RuntimeIdentifiers
RuntimeIdentifiers可設置的內容可以參考上面的平台支持
為對應的平台進行發布
最終你的項目文件可以像下面這樣
執行發布命令
dotnet publish –c Release –r win-x64
dotnet publish –c Release –r linux-x64
我們就可以去具體的發布輸出目錄看到發布結果了
可以看到大小為3.7MB還是有優化的空間的，畢竟現在還不是正式版。
go引用fmt后的build大小差不多是1.9MB。
CoreRT目前存在的最大問題
CoreRT為什么不推薦大家現在使用？很大的一個問題就是現有所有用到反射的類型，都必須制定一個Mapping文件。異常麻煩。配置文件內容大概如下：
泛型也行也得一個個完全去指定，所以不推薦大家在太復雜的應用下使用。當然官方最終應該不會允許這個文件存在的。目前官方已經開了對應的issue用來討論如何解決這個現狀。
我們就再耐心等等吧。