Mono准备好进入黄金时段了吗?

.net open-source mono


是否有人在大型或中型项目上使用过Mono.NET的开源实现?我想知道它是否已准备好用于现实世界的生产环境。它稳定,快速,兼容...足以使用吗?将项目移植到Mono运行时是否需要花费很多精力,还是真的,真的足够兼容以仅接受和运行Microsoft的运行时已编写的代码?




Answer 1 miguel.de.icaza


有几种情况需要考虑。(a)如果你正在移植一个现有的应用程序,并想知道Mono是否足以胜任这项任务;(b)你开始编写一些新的代码,并想知道Mono是否足够成熟。

对于第一种情况,您可以使用Mono迁移分析器工具(Moma)评估您的应用程序在Mono上的运行距离。如果评估结果令人满意,则应开始进行测试和质量检查,并准备发货。

如果你的评估报告突出了Mono中缺失的功能或与它们的语义有很大的不同,你将不得不评估代码是否可以调整、重写,或者在最坏的情况下,你的应用程序是否可以在功能减少的情况下工作。

根据我们基于用户提交的Moma统计(这是记忆中的数据),大约50%的应用程序可以开箱即用,大约25%的应用程序需要花费一周的时间(重构、改编),另外15%的应用程序需要花大力气重做大块的代码,其余的应用程序则不值得费心去移植,因为它们与Win32的联系非常紧密。在这一点上,要么你从零开始,要么商业决策将推动你的代码可移植的努力,但我们说的是几个月的工作(至少从我们的报告来看)。

如果你从头开始,情况就简单多了,因为你将只使用Mono中存在的API。只要你坚持使用支持的协议栈(几乎是.NET 2.0,加上3.5中所有的核心升级,包括LINQ和System.Core,再加上任何Mono的跨平台API),你就可以了。

每隔一段时间,你可能会遇到Mono的bug或限制,你可能不得不绕过它们,但这与其他系统没有什么不同。

至于可移植性。ASP.NET应用程序是比较容易移植的,因为这些应用程序对Win32几乎没有依赖性,你甚至可以使用SQL服务器或其他流行的数据库(Mono有很多捆绑的数据库提供者)。

Windows.Forms 移植有时比较棘手,因为开发人员喜欢逃避 .NET 沙箱,P/Invoke 绞尽脑汁地配置一些有用的东西,比如改变光标的闪烁率,用 wParam 中以 BCD 形式编码的两个 bezier 点表示。或者类似的一些垃圾。




Answer 2 Jon Galloway


它有相当广泛的覆盖面,直到.NET 4.0,甚至包括.NET 4.5 APIs的一些功能,但有一些领域,我们选择不实现,因为API被废弃,新的替代品被创建或范围太大。以下API在Mono中不可用。

  • Windows Presentation Foundation
  • Windows工作流基金会(两个版本都没有)
  • 实体框架
  • WSE1/WSE2标准Web服务栈的 "附加功能"。

此外,我们的WCF实现仅限于Silverlight支持的内容。

检查特定项目的最简单方法是运行Mono Migration Analyzer(MoMA)。好处是它将通知Mono团队有关问题的信息,这将阻止您使用Mono(如果有),从而使他们可以优先处理工作。

我最近在SubSonic上运行MoMA,只发现了一个问题--Nullable类型的奇怪使用。那是一个很大的代码库,所以那里的覆盖率相当惊人。

Mono在几种商业以及开源产品中得到了积极的应用。它已在Wikipedia和Mozilla开发人员中心等某些大型应用程序中使用,并已在Sansa MP3播放器等嵌入式应用程序中使用,并为成千上万的已发布游戏提供支持。

在语言级别,Mono编译器完全符合C#5.0语言规范




Answer 3 FlySwat


在桌面方面,如果你使用GTK#的话,Mono的效果非常好。Windows.Forms的实现仍然有一些bug (例如,TrayIcon不能用),但它已经有了很大的进步。此外,GTK#是一个比Windows Forms更好的工具箱。

在Web方面,Mono已经实现了足够的ASP.NET,可以完美运行大多数网站。这里的难点是找到一个在apache上安装了mod_mono的主机,或者如果你有shell权限的话,可以自己动手。

无论哪种方式,Mono都很好,而且稳定。

创建跨平台程序时要记住的关键事项。

  • 使用GTK#代替Windows.Forms
  • 确保文件名的大小写正确
  • 使用 Path.Separator 代替硬编码 "\" ,也使用 Environment.NewLine 代替 "\n"
  • 不要对Win32 API使用任何P/Invoked调用。
  • 不要使用Windows注册表。



Answer 4 damageboy


我个人在黄金时间环境中使用Mono。我运行的Mono服务器需要处理千兆字节的udp/tcp数据处理相关任务,我非常高兴。

有一些特殊性,其中最烦人的是,由于Mono目前的状态,你不能直接 "建立 "你的msbuild文件。

  • MonoDevelop (IDE)有部分的msbuild支持,但除了简单的hello-world(自定义构建任务、动态 "属性 "如$(SolutionDir)、真实配置等几个死胡同)之外,基本上会在任何 "真实 "的构建conf上失效。
  • xbuild 应该是由单机提供的msbuild-完全兼容-build -system更加可怕,因此从命令行进行构建实际上比使用GUI更糟糕,这是GUI的非常“非常规”状态。 Linux环境联盟...

一旦/在让你的东西真正BUILT的过程中,你可能会看到一些野蛮的代码,甚至是应该被支持的代码,比如。

  • 编译器在某些结构上出了问题。
  • 和某些更高级/新的.NET类向你扔出意想不到的垃圾(XLinq有人吗?
  • 一些不成熟的运行时 "功能"(x64上的3GB堆限制...WTF!)。

但是他说,一般来讲,事情开始很快,解决方案/解决方法很多

一旦您克服了这些最初的障碍,我的经验就是mono ROCKS,并且每次迭代都会变得越来越好

我的服务器用单片机运行,每天处理300GB的数据,有大量的p/invokes,一般来说,做了大量的工作,并保持了5-6个月的时间,即使是 "流血的边缘 "单片机。

希望对你有所帮助。




Answer 5 Kris Erickson


接受答案的建议现在有点过时了。

  • Windows窗体的实现现在非常好。(有关Paint.net的端口,请参见Paint-Mono,Paint.net是一个非常复杂的Windows窗体应用程序。所需要的只是一些P-Invoke和不受支持的系统调用的仿真层)。
  • Path.Combine以及Path.Seperator来连接路径和文件名。
  • windows注册表是可以的,只要你只用它来存储和检索应用程序中的数据(即你不能从它那里得到任何有关Windows的信息,因为它基本上是Mono应用程序的注册表)。