有人在大型或中型项目中使用过 Mono（开源 .NET 实现）吗？我想知道它是否适合现实世界的生产环境。它稳定、快速、兼容……足以使用吗？将项目移植到 Mono 运行时是否需要花费很多精力，或者确实如此，really是否足够兼容以获取并运行已为 Microsoft 运行时编写的代码？
有几个场景需要考虑：(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 中的错误或限制，并且您可能必须解决它们，但这与任何其他系统没有什么不同。
至于可移植性：ASP.NET 应用程序更容易移植，因为它们几乎不依赖于 Win32，甚至可以使用 SQL Server 或其他流行的数据库（有很多与 Mono 捆绑的数据库提供程序）。
Windows.Forms 移植有时会比较棘手，因为开发人员喜欢逃离 .NET 沙箱，并绞尽脑汁进行 P/Invoke 来配置一些有用的内容，例如更改光标闪烁率（表示为 wParam 中以 BCD 形式编码的两个贝塞尔点）。或者类似的垃圾。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
