使用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

支持的平台

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上同樣也需要單獨進行一次發布（當然還包括x86x64ARM這樣的變更，都需要重新發布）

同樣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用來討論如何解決這個現狀。

我們就再耐心等等吧。

原文：https://www.cnblogs.com/justmine/p/8630332.html

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！