在DNX上，当我们使用dnu publish发布一个应用程序时，我们会为project.json中定义的每个命令获取一个脚本，该脚本执行所需的操作使用dnx.exe。这里重要的一点是，应用程序本身的执行是由 dnx .
根据我的理解，DNX是虚拟机(CLR或CoreCLR(和操作系统之间的接口。在这种情况下，调用 DNX 将启动所选虚拟机，处理依赖项并在那里启动应用程序。
使用新的.NET CLI，情况就不同了。当我们发布dotnet publish应用程序时，除了其他内容外，我们还会收到文件projectname.dll，projectname.pdb和一个本机可执行项目名称。
此处的执行直接通过应用程序完成。没有中间过程的软件。我们运行本机可执行文件，据我了解，它可以启动CLR，与操作系统接口并运行应用程序。
主要区别在于，DNX在执行应用程序的操作系统中安装了一个独特的软件。 对于每个应用程序，我们都有一个本机可执行文件，它似乎可以完成DNX的工作。
似乎从一种方法到另一种方法已经发生了巨大的转变。我的问题是：这一巨大转变的动机是什么？为什么要放弃第一种方法，而转向第二种方法来执行应用程序？
dnx 的缺点之一是 dnx 的依赖项毒害了您的应用程序。使用 dnx，有一个本机引导程序来引导 Clr/CoreClr，然后在实际应用程序执行之前运行一些托管代码。此托管代码需要依赖项。如果应用程序碰巧使用相同的依赖项(可能不同的版本(，则它不会使用应用程序引用的版本，而是使用 dnx 引用的版本。因此，dnx 有效地固定了依赖项(您是否曾经注意到dnu build会失败但dnx run可以正常工作的情况 - 这是因为导致构建失败的依赖项是由 dnx 带来的(。有趣的是，这是dnx停止在内部使用 JSon.NET 并拥有自己的JSon解析器(github上史诗般的"我们不再支持project.json中的注释"线程(的原因之一 - 不固定 JSon.Net 的版本。
在 dotnet 中，引导程序和代码之间没有托管代码。您的.exe只是一个重命名的引导程序 (corerun.exe(，它引导运行时并调用您的应用程序。 dotnet cli 实际上只是一组工具，运行时是应用程序所依赖的一组包(如果您使用的是 CoreClr(。是的，运行时不再有编译(dotnet run首先将应用程序编译为.exe，然后运行它(。我认为共享运行时在未来是可能的。