使用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用来讨论如何解决这个现状。

我们就再耐心等等吧。