.NET Core如何在.NET Framework的内部实现方面区别于程序的构建和运行方式？我知道常规的.NET Framework / C＃项目基本上被编译成CIL代码，分发，然后由JITer在运行时编译，最终将它们逐个函数地转换为机器代码（除非程序员指定了预编译选项）。这对于.NET Core应用程序也是如此吗？是否有主要差异？
注意事项：
是的，我知道这两件事都非常复杂，我不希望回答者详细解释每一个小部件。
我之前听说过.NET Framework的CLR之前被称为虚拟机，但我知道这是有争议的，并且在this one这样的帖子中看到了这样的争论，就像CIL与Java的字节码的比较一样。这些是无聊的论点，与问题无关。
我发现了类似的问题，然而，问题似乎集中在.NET Core在功能/可用性方面与客户程序员的区别。这个问题与此无关，而是在内部实现方面询问.NET Core与.NET Framework的不同之处。
谢谢。
答案 0 :(得分：2)
IL或JIT流程没有区别。我有旧的.NET代码直接执行IL，在Core上工作正常。它们都完全实现了CLI ECMA standard，它们都具有相同的运行时组件。
每个平台的实现可能存在非常细微的差异，因为Windows .NET和Mono之间存在差异，但我不知道。
CLI步骤和框架实际上是不同的东西：您可能构建C＃代码，无需.NET或Core即可编译为有效的IL，但我不确定如果没有原始类型，您实际上可以做什么。
差异几乎完全在受支持的框架中 - 虽然全胖.NET与Windows绑定，.NET Standard libraries是真正的跨平台。
这个问题太大了：已经齐心协力将.NET中的所有内容移植到.NET Standard 1.5上，但是有很多内容。对于.NET Core，有几个地方有一个全新的范例（例如ASP.MVC和ASP Core MVC完全不同）。您可能会更好地将问题缩小到特定区域和平台。
很快所有 .NET将运行在.Net Standard 2.0库和.NET Framework 4/5 /任何只是遗留和仅Windows的组件（WPF，WinForms等）上跑在上面。