【发布时间】：2015-02-07 06:50:09
【问题描述】：
有人可以向我解释一下 Mono 与 Microsoft 最近提供的开源/Linux 可移植 .NET 堆栈（CoreCLR、CoreFX、Roslyn、ASP.NET）之间的当前关系是什么？
很明显这些项目重叠，所以我很好奇它们的路线图是什么 - Mono 会以某种方式用微软的新组件替换他们自己的组件，还是它们会以某种方式共存？
【问题讨论】：
标签： .net mono .net-core coreclr
【发布时间】：2015-02-07 06:50:09
【问题描述】：
我认为答案可能会随着时间的推移而演变，但我知道微软和 Mono Project 将一起工作，或者至少微软将允许 Mono 使用他们的开源 .Net 堆栈。
http://www.mono-project.com/docs/about-mono/releases/4.0.0/
虽然 Microsoft 正在努力开发 .NET Core：一个可再发行和重新构想的 .NET 版本，但该项目仍在进行中。 Mono 目前继续提供跟踪 .NET 桌面/服务器版本的 API。
这意味着我们集成的大部分代码都来自 ReferenceSource 拖放。未来，我们将提供与 .NET Core 相同的“Mono Core”，以允许将 Mono 运行时与使用 CoreFX 开发的新库分发系统一起使用。
Miguel de Icaza（Xamarin 的首席技术官兼联合创始人和 Mono 项目的创始人）评论说：
http://tirania.org/blog/archive/2014/Nov-12.html
.NET 在 MIT 许可下开源。不仅代码是在这种非常宽松的许可下发布的，而且微软还提供专利承诺，以确保 .NET 得到应有的采用。
特别是对于这两个项目：
Mono 将能够从这个项目中尽可能多地使用它。
...
Microsoft 已表示，他们目前不打算收回补丁或参与此代码库的完全开源社区风格的开发，因为对 Windows 的向后兼容性的要求非常高。
【讨论】：
From a Mono contributor on reddit:
我认为人们对整个 Mono/CoreCLR 情况的看法是错误的。为什么一个VM成为开源并移植到其他操作系统意味着另一个VM不能存在？这就好像说应该只有一个 Python 实现或一个 JVM。那不是一件好事。竞争是健康的。
Mono 恰好有很多 CoreCLR 没有的特性：LLVM、完整的 AOT、NaCl、tasklet、跨 VM GC 桥、各种分析器模块等。Mono 的启动时间和运行时内存占用也针对平台进行了优化/devices CoreCLR （至少目前）甚至没有针对。 OTOH，CoreCLR 具有更成熟的 GC 和通常更好的代码生成（因此启动时间更慢）。两个虚拟机擅长不同的事情，没有理由不能同时存在。
我们也不坚持保留自己的代码。当这样做有明显的好处（更少的维护，更正确，仍然足够便携）时，我们很高兴切换到 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
核心框架库 (CoreFX) - https://github.com/dotnet/corefx - 用于所有 .NET Core 场景，包括 .NET Native (UWP)。这意味着您的代码在所有这些不同的环境中执行相同的操作，因为它使用相同的底层框架库。另外，Mono 项目使用了很多相同的代码，这意味着 Xamarin 应用程序的基本框架也变得更加兼容 CoreFX。是啊！我们希望在未来使这更加正式。我们经常与@migueldeicaza 讨论这个问题。
基本上，它们之间发生了很多代码共享，如果它们将来会聚，我不会感到惊讶。既然 MS 已经收购了 Xamarin，我认为他们不会对维护两个运行时非常感兴趣。
【讨论】：