使用CoreRT將.NET Core發佈爲Native應用程序

在上一篇文章《使用.NET Core快速開發一個較正規的命令行應用程序》中咱們看到了使用自包含方式發佈的.NET Core應用中包含了216個文件。我就寫一個cat命令用得着這麼動真格。。。這寫出來的命令行還有人用嗎？今天咱們就來介紹一下MS的另外一個開源項目CoreRT。用來解決這個棘手的問題。

什麼是CoreRT？

CoreRT 是MS一個長期開源項目，它早在一年前就已經創建了，持續到今。

項目目標

將.NET Core託管（CLR）應用程序編譯爲本地（特意平臺）的單一可執行文件。

說白了就是將.NET Core編譯爲機器碼（也能夠是其餘東西，如C++代碼），而再也不有以前的運行時，將.NET變爲真正的「靜態編譯形」語言。

基本信息

項目地址：https://github.com/dotnet/corert

支持的平臺

1. Windows x64
2. MacOS x64
3. Linux x64/ARM
4. CppCodeGen
5. 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用來討論如何解決這個現狀。

咱們就再耐心等等吧。