13

有人可以向我解释一下 Mono 与 Microsoft 最近提供的开源/Linux 可移植 .NET 堆栈(CoreCLR、CoreFX、Roslyn、ASP.NET)之间的当前关系是什么?

很明显这些项目重叠,所以我很好奇它们的路线图是什么 - Mono 会以某种方式用微软的新组件替换他们自己的组件,还是它们会以某种方式共存?

4

2 回答 2

2

我认为答案可能会随着时间的推移而发展,但我理解微软和 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 将能够从这个项目中尽可能多地使用它。

...

微软表示,他们目前不打算收回补丁或参与该代码库的完全开源社区风格的开发,因为对 Windows 的向后兼容性的要求非常高。

于 2015-04-14T03:46:56.470 回答
0

来自 reddit 上的 Mono 贡献者:

我认为人们对整个 Mono/CoreCLR 情况有错误的心态。为什么一个VM成为开源并移植到其他操作系统意味着另一个VM不能存在?这就好像说应该只有一个 Python 实现或一个 JVM。那不是一件好事。竞争是健康的。

Mono 恰好有很多 CoreCLR 没有的特性:LLVM、完整 AOT、NaCl、tasklet、跨 VM GC 桥、各种分析器模块等。Mono 的启动时间和运行时内存占用也针对平台/设备进行了优化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

来自 HN 上的 .NET 成员:

核心框架库 (CoreFX) - https://github.com/dotnet/corefx - 用于所有 .NET Core 方案,包括 .NET Native (UWP)。这意味着您的代码在所有这些不同的环境中执行相同的操作,因为它使用相同的底层框架库。另外,Mono 项目采用了很多相同的代码,这意味着 Xamarin 应用程序的基本框架也变得与 CoreFX 更加兼容。是啊!我们希望在未来使这更加正式。我们经常与@migueldeicaza 讨论这个问题。

基本上它们之间发生了很多代码共享,如果它们将来会聚,我不会感到惊讶。既然 MS 已经收购了 Xamarin,我认为他们不会对维护两个运行时非常感兴趣。

于 2016-04-28T12:21:32.097 回答