与 DNX 和 .NET CLI 不同的执行方式

Question

在 DNX 上，当我们使用dnu publish 发布一个应用程序时，我们会为project.json 中定义的每个命令获得一个脚本，该脚本使用dnx.exe 执行所需的操作。这里的重点是应用程序本身的执行是由dnx 完成的。

据我了解，DNX 是虚拟机（CLR 或 CoreCLR）与操作系统之间的接口。在这种情况下，调用 DNX 将启动选择的虚拟机，处理依赖关系并在那里启动应用程序。

有了新的 .NET CLI，情况就不同了。当我们使用dotnet publish 发布应用程序时，除了其他内容之外，我们还得到文件 projectname.dll、projectname.pdb 和一个本机可执行文件 projectname em>。

这里的执行是直接通过应用程序完成的。没有中间过程的软件。我们运行本机可执行文件，据我了解，它会启动 CLR、与操作系统交互并运行应用程序。

主要区别在于 DNX 在执行应用程序的操作系统中安装了一个独特的软件。为每个应用程序使用 .NET CLI，我们有一个本机可执行文件，似乎可以完成 DNX 的工作。

似乎从一种方法到另一种方法发生了巨大转变。我的问题是：这种巨大转变的动机是什么？为什么要放弃第一种方法并转而使用第二种方法来执行应用程序？

Answer 1

dnx 的一个缺点是 dnx 会通过其依赖项毒害您的应用程序。使用 dnx 有一个本机引导程序，它引导 Clr/CoreClr，然后是一些在实际应用程序执行之前运行的托管代码。此托管代码需要依赖项。如果应用程序碰巧使用相同的依赖项（可能不同的版本），它不会使用应用程序引用的版本，而是使用 dnx 引用的版本。所以，dnx 有效地固定了依赖项（你有没有注意到dnu build 会失败但dnx run 会正常工作的情况 - 这是因为导致构建失败的依赖项是由 dnx 带来的）。有趣的是，这也是 dnx 在内部停止使用 JSon.NET 并拥有自己的 JSon 解析器（github 上的史诗“我们不再支持 project.json 中的 cmets”线程）的原因之一——不固定 JSon.Net 的版本。

在 dotnet 中，引导程序和您的代码之间没有托管代码。您的 .exe 只是一个重命名的引导程序 (corerun.exe)，它引导运行时并调用您的应用程序。 dotnet cli 实际上只是一组工具，运行时是您的应用程序所依赖的一组包（如果您使用的是 CoreClr）。是的，运行时不再进行编译（dotnet run 首先将应用程序编译为 .exe，然后运行它）。我认为共享运行时是未来的可能性。