.NET Core 与.NET Native 发展现状

“本文最初发布于 Mark Rendle 的博客，经原作者授权由 InfoQ 中文站翻译并分享。”

笔者在 Linux 上安装了.Net Core runtime，并对新的 CLI、CoreRT、ASP.Net Core 进行了简单的测试与分析。

在之前文章中，我终于将整个.Net Core runtime 和工具都安装到我工作用的 Linux 笔记本了，包括了：

• 含 CoreCLR runtime 的 ASP.NET Core 1.0-rc1
• 新的 .NET CLI

(根据命名声明，从现在起我将会把 ASP.NET 5 写成 ASP.NET Core)

昨晚，我开始尝试在 CoreCLR/CoreFx 上运行各种当前能在 Mono runtime 上运行的 ASP.NET Core 项目。 到目前为止它们都能工作，虽然我确实将那些我认为有问题的项目留到了最后，尤其是那些使用了 Azure Storage SDK 中较边缘部分的项目。:)

我在台式机上尝试通过那些能同时在 CoreCLR 和 Mono 的 Docker 容器中运行的各种服务来执行一些负载测试，我将会在这里公开那些实验结果。

我过去的两天里挖遍了 GitHub 上 dotnet 组织的各个仓库之后，我所见到的让我感到很兴奋。当然，我说的不仅仅是在 Linux 上运行。

新的 CLI

新的 dotnet CLI 与我大约在去年使用过的 dnx, dnu 和 dnvm 命令有很大差别。那些都是 shell 脚本（或 Bash 函数）；如果你执行一下 catwhich dnx`` 就能看见脚本，它用 Mono 运行一个.Net DLL。

但如果你执行 catwhich dotnet`` 你将会得到满屏的乱码，因为dotnet是一个本机执行文件。

我不知道现在那边具体发展成怎样了。在dotnet-nightly 文件夹里翻一下，有很多大小相近的本机执行文件，这挺怪异的，或许它们只是.Net 程序集的装载器，但也挺酷的。

CoreRT

由于好奇让这一切成为可能的基础，我进入了 CoreRT 仓库，里面对 CoreRT 的描述是这样的

一个为 AOT（ahead of time compilation）场景优化的.NET Core runtime，附带.NET Native 编译器工具链。

然而什么是工具链呢？

我找到了隐藏在文档目录中的 intro-to-corert.md 文件，其中解析了具体的情况。

这个项目的开发者（我想应该包含所有在微软内外的贡献者）正在构建一套工具，可以将 MSIL byte-code（由 Roslyn 编译 C#代码产生）预先编译成本机 x86/64 机器编码。

最初默认的实现使用新的 64-bit CLR JIT 编译器（去年夏天发布）RyuJIT 来产生机器编码，但工具链还可以使用其他编译器，包括它们自己引用的 IL-to-C++ compiler (难以置信的小巧) and LLILC ，这个是建基于 LLVM 的 CoreCLR 中正在使用的 JIT 编译器，而且将来打算支持 AOT 编译。

关于 JIT 与 AOT 的简易备注

.NET CLR 包含一个 Just-In-Time (JIT) 编译器负责把 MSIL bytecode 转换成本机机器编码。它在你应用程序运行的时候进行转换，而且它是在各方法第一次被调用的时候才进行转换的；因此，“just in time”。这就是为什么同一个程序集能够在不同的 CPU 和操作系统上使用。

JIT 编译器，一般来说，是优化成尽可能快地完成编译，而不是产生尽可能好的机器编码。

一个 Ahead-Of-Time (AOT) 编译器，能为特定的目标 CPU 和操作系统把所有 MSIL bytecode 预先转换成本机机器编码，所以你无需单独的 runtime 就能够分发应用或程序库。

因为 AOT 编译器不像 JIT 编译器那样有微观时间的限制，在大部分情况下能够产生更高效、优化度高的机器编码。

CoreRT 自身以 CoreCLR 和程序库的修改版本呈现，用不同的方式进行组织，对依赖项也进行过清理。我猜测至少有些部分开启了更高效的无用代码删除（dead code elimination），使其二进制文件尽可能的小。

所有这些意味着C#即将进入 Go 的领地 - 一个跨平台、本地编译、带垃圾回收的编程语言。除此之外，C#当然拥有现代语言的特点，比如泛型、async/await 等等。

本机 ASP.NET Core

在同一个页面， Roadmap的下面，有这样的描述：

开始，我们的目标是本机可执行（又称“控制台程序”）。之后，我们将会把它扩展到包括 ASP.NET 5 程序…

而且除了当前 ASP.NET Core 网站应用的“XCOPY 部署”模型 - 简单地转存一个目录树到服务器外，我们还可以期待“COPY 部署”模型 - 仅转存一个单独的可执行文件。就如同一页面所述，这会导致 Dockerfile 看上去像下面这样：

 
FROM debian:jessie
 
EXPOSE 5000
 
ADD mycompiledapp.exe /  
# The .exe is just there to make a point :)
 
ENTRYPOINT /mycompiledapp

还不清楚这工具链是否能静态链接非.NET 程序库（例如 libuv 或者 libcurl）到本机二进制文件，还是需要以动态链接.dll 或 .so 文件的形式一并安装。两种形式，都将制成十分小巧的 Docker 映像，而且容器的启动也会非常快，不过，这一连串的想法很快引起了对 unikernels 的期待，.NET Native 将来会否支持呢？

初步的答案，至少看上去是 “会。会支持的。”

这些项目明显都在初级阶段，所以没必要太早地兴奋过头，免得将来在roadmap 上有些东西会被残忍地杀掉，但总而言之，是时候成为一个C#开发者了。

致谢：我是受 Tugberk Ugurlu 最近关于这方面的部落文章激发才跳入这个兔子窝的。

原文链接： https://blog.rendle.io/what-ive-learned-about-dotnet-native

编后语
《他山之石》是 InfoQ 中文站新推出的一个专栏, 精选来自国内外技术社区和个人博客上的技术文章, 让更多的读者朋友受益, 本栏目转载的内容都经过原作者授权。文章推荐可以发送邮件到 editors@cn.infoq.com。