Microsoft .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将以某种方式用Microsoft的新组件替换其自己的组件，还是它们将以某种方式共存?
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，完整的AOT，NaCl，tasklet，跨VM GC桥接器，各种探查器模块等.Mono的启动时间和运行时内存占用也针对平台进行了优化. /devices(甚至至少目前)没有针对CoreCLR进行定位. OTOH，CoreCLR具有更成熟的GC和通常更好的代码生成(因此启动时间较慢).两种VM擅长于不同的事情，没有理由两者都不存在.
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.
这篇关于Microsoft .NET开源后的CoreCLR和项目Mono关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
