在上一篇文章《使用.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-*
设置RuntimeIdentifiersRuntimeIdentifiers可设置的内容可以参考上面的平台支持
为对应的平台进行发布最终你的项目文件可以像下面这样
执行发布命令
dotnet publish –c Release –r win-x64
dotnet publish –c Release –r linux-x64
我们就可以去具体的发布输出目录看到发布结果了
可以看到大小为3.7MB还是有优化的空间的，毕竟现在还不是正式版。
go引用fmt后的build大小差不多是1.9MB。
CoreRT目前存在的最大问题CoreRT为什么不推荐大家现在使用？很大的一个问题就是现有所有用到反射的类型，都必须制定一个Mapping文件。异常麻烦。配置文件内容大概如下：