微软开源 .NET 后 CoreCLR 与项目 Mono 的关系 [英] CoreCLR and project Mono relationship after Microsoft open-sourced the .NET
问题描述
有人可以向我解释一下 Mono 与 Microsoft 最近提供的开源/Linux 可移植 .NET 堆栈(CoreCLR、CoreFX、Roslyn、ASP.NET)之间的当前关系吗?
Could someone explain to me what is the current relationship between Mono and the open source/Linux portable .NET stack (CoreCLR, CoreFX, Roslyn, ASP.NET) recently made available by Microsoft?
很明显这些项目重叠，所以我很好奇他们两个的路线图是什么 - Mono 会以某种方式用微软的新组件替换他们自己的组件，还是它们会以某种方式共存?
It's rather clear these projects overlap so I'm curious what's the roadmap for both of them - will Mono somehow replace their own component with the new ones from Microsoft, or are they going to coexist somehow?
推荐答案
我认为人们对整个 Mono/CoreCLR 情况的看法是错误的.为什么一个虚拟机开源并移植到其他操作系统意味着另一个虚拟机不能存在?这就像说应该只有一个 Python 实现或一个 JVM.这可不是什么好事.竞争是健康的.
I think people have the wrong mindset about this whole Mono/CoreCLR situation. Why should one VM becoming open source and being ported to other OSs mean that another VM can't exist? It'd be like saying that there should only be one Python implementation, or one JVM. That is not a good thing. Competition is healthy.
Mono 恰好有很多 CoreCLR 没有的特性:LLVM、full AOT、NaCl、tasklets、跨 VM GC 桥、各种分析器模块等. Mono 的启动时间和运行时内存占用也针对平台进行了优化CoreCLR(至少目前)甚至没有针对的/devices.OTOH，CoreCLR 有更成熟的 GC 和更好的代码生成(因此启动时间更慢).两个虚拟机擅长的东西不同，没有理由不能同时存在.
Mono happens to have a lot of features that CoreCLR doesn't: LLVM, full AOT, NaCl, tasklets, cross-VM GC bridge, various profiler modules, etc. Mono's startup time and runtime memory footprint are also optimized for platforms/devices that CoreCLR isn't (at least presently) even targeting. OTOH, CoreCLR has a more mature GC and generally better code generation (hence the slower startup time). The two VMs are good at different things, and there is no reason both cannot exist.
我们也没有坚持保留自己的代码.如果这样做有明显的好处(更少的维护，更正确，仍然足够便携)，我们很高兴切换到 CoreCLR/参考源代码.我们已经导入了大量的参考源代码，我们还导入了 CoreCLR VM 的某些部分:
https://github.com/mono/mono/blob/master/mono/metadata/decimal-ms.c
https://github.com/mono/mono/blob/master/mono/metadata/threadpool-ms.c
It's not like we insist on keeping our own code either. We're happy to switch to CoreCLR/reference source code when there are clear benefits to doing so (less maintenance, more correct, still portable enough). We've imported tons of reference source code already, and we're also importing certain parts of the CoreCLR VM:
https://github.com/mono/mono/blob/master/mono/metadata/decimal-ms.c
https://github.com/mono/mono/blob/master/mono/metadata/threadpool-ms.c
核心框架库 (CoreFX) - https://github.com/dotnet/corefx- 用于所有 .NET Core 方案，包括 .NET Native (UWP).这意味着您的代码在所有这些不同的环境中做同样的事情，因为它使用相同的底层框架库.另外，Mono 项目采用了大量相同的代码，这意味着 Xamarin 应用程序的基础框架也越来越与 CoreFX 兼容.耶！我们希望在未来使这更加正式.我们经常与@migueldeicaza 讨论这个问题.
The core framework libraries (CoreFX) - https://github.com/dotnet/corefx - are used for all .NET Core scenarios, including .NET Native (UWP). This means that your code does the same thing in all of these different environments, since it's using the same underlying framework libraries. Separately, the Mono project is taking a lot of the same code, which means that the base framework for Xamarin apps are becoming more compatible with CoreFX, too. Yeahh! We hope to make this more formal in the future. We talk to @migueldeicaza about this frequently.
基本上，它们之间发生了很多代码共享，如果它们将来融合，我不会感到惊讶.既然 MS 收购了 Xamarin，我认为他们不会对维护两个运行时非常感兴趣.
Basically there's a lot of code sharing happening between them and I wont be surprised if they converge in future. Now that since MS has acquired Xamarin I dont think they will be terribly interested in maintaining two runtimes.
这篇关于微软开源 .NET 后 CoreCLR 与项目 Mono 的关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
