微软开源.NET后,CoreCLR和项目Mono关系

时间:2015-02-07 06:50:09

标签: .net mono .net-core coreclr

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

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

2 个答案:

答案 0 :(得分:2)

我认为答案可能会随着时间的推移而发展,但我理解Microsoft和Mono Project将协同工作,或者至少Microsoft会允许Mono使用他们的开源.Net堆栈。

  

http://www.mono-project.com/docs/about-mono/releases/4.0.0/

     

虽然微软正致力于.NET Core:一个可再发行且重新设想的.NET版本,但该项目仍在进行中。 Mono此时继续提供跟踪.NET桌面/服务器版本的API。

     

这意味着我们集成的大多数代码都来自ReferenceSource drop。在未来,我们将在.NET Core的同一行中提供“Mono Core”,以允许Mono运行时与使用CoreFX开发的新库分发系统一起使用。

Miguel de Icaza(Xamarin的CTO兼联合创始人和Mono项目的创始人)评论说:

  

http://tirania.org/blog/archive/2014/Nov-12.html

     

.NET是在MIT许可下开源的。代码不仅是在这个非常宽松的许可下发布的,而且微软正在提供专利承诺,以确保.NET能够得到应有的采用。

特别是两个项目:

  

Mono将能够从这个项目中尽可能多地使用它。

     

...

     

微软已声明他们目前不打算采用补丁或参与此代码库的完整开源社区风格开发,因为对Windows的向后兼容性要求非常高。

答案 1 :(得分:0)

From a Mono contributor on reddit:

  

我认为人们对整个Mono / CoreCLR情况有错误的心态。为什么一个虚拟机成为开源并被移植到其他操作系统意味着另一个虚拟机不能存在?这就像说应该只有一个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

From a .NET member on HN:

  

核心框架库(CoreFX) - https://github.com/dotnet/corefx - 用于所有.NET Core场景,包括.NET Native(UWP)。这意味着您的代码在所有这些不同的环境中执行相同的操作,因为它使用相同的底层框架库。另外,Mono项目采用了大量相同的代码,这意味着Xamarin应用程序的基础框架也变得与CoreFX更加兼容。 Yeahh!我们希望将来能够更加正式化。我们经常与@migueldeicaza谈论此事。

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