有人在大型或中型项目中使用过。net开源实现Mono吗?我想知道它是否已经为现实世界的生产环境做好了准备。它是否稳定、快速、兼容……足够用了吗?将项目移植到Mono运行时是否需要花费大量的精力,或者它是否真的足够兼容,只需要为微软的运行时编写代码就可以了?
当前回答
你知道Mono 2.0预览版对Windows Forms 2.0的支持有多好吗?
从我使用它的一小部分来看,它似乎相对完整,几乎可用。它只是在一些地方看起来不太对,总的来说还是有点命中或错过。说实话,它和我们的一些表格一样好用,这让我很惊讶。
其他回答
这里有几个场景需要考虑:(a)如果你正在移植一个现有的应用程序,并且想知道Mono是否足够好来完成这个任务;(b)你开始写一些新代码,你想知道Mono是否足够成熟。
对于第一种情况,您可以使用Mono迁移分析工具(Moma)来评估您的应用程序距离在Mono上运行还有多远。如果评估结果令人满意,你就应该开始测试和QA工作,并准备发布。
如果你的评估返回的报告强调了在Mono中缺失的功能或语义上的显著差异,你将不得不评估代码是否可以改编,重写,或者在最坏的情况下,你的应用程序是否可以在功能减少的情况下工作。
According to our Moma statistics based on user submissions (this is from memory) about 50% of the applications work out of the box, about 25% require about a week worth of work (refactoring, adapting) another 15% require a serious commitment to redo chunks of your code, and the rest is just not worth bothering porting since they are so incredibly tied to Win32. At that point, either you start from zero, or a business decision will drive the effort to make your code portable, but we are talking months worth of work (at least from the reports we have).
如果您从头开始,情况就简单多了,因为您将只使用Mono中存在的api。只要你继续使用支持的堆栈(基本上是。net 2.0,加上3.5的所有核心升级,包括LINQ和System)。核心,加上任何Mono跨平台api)你会很好。
每隔一段时间,你可能会在Mono中遇到bug或限制,你可能不得不解决它们,但这与其他系统没有什么不同。
至于可移植性:ASP。NET应用程序更容易移植,因为它们对Win32几乎没有依赖,你甚至可以使用SQL server或其他流行的数据库(Mono中有很多捆绑的数据库提供商)。
窗户表单移植有时比较棘手,因为开发人员喜欢逃离。net沙盒,用P/Invoke来配置一些有用的东西,比如用wParam中BCD格式编码的两个bezier点来表示改变光标闪烁速率。或者类似的垃圾。
在许多情况下,你可以获取现有的代码并在Mono上运行,特别是如果你正在移植一个ASP。网络应用程序。
在某些情况下,您可能需要全新的代码段才能使其工作。如果你使用System.Windows。例如,如果不修改表单,应用程序将无法工作。同样,如果您使用任何特定于windows的代码(例如,注册表访问代码)。但我认为最糟糕的是UI代码。这在麦金塔系统上尤其糟糕。
如果你想使用WPF,那你就不走运了,Mono目前还没有计划实现它。
http://www.mono-project.com/WPF
在桌面端,如果您承诺使用gtk#, Mono工作得很好。窗户。表单实现仍然有一些bug(例如,TrayIcon的不能工作),但它已经取得了很大的进步。此外,gtk#是一个比Windows窗体更好的工具包。
在web端,Mono已经实现了足够多的ASP。NET可以完美地运行大多数网站。这里的困难是找到一个在apache上安装了mod_mono的主机,或者如果你有shell访问你的主机,你自己做。
不管怎样,Mono都很棒,而且很稳定。
创建跨平台程序时需要记住的关键事项:
使用gtk#而不是Windows。形式 确保文件名的大小写正确 使用路径。分隔符而不是硬编码“\”,也使用环境。换行,而不是“\n”。 不要使用任何P/Invoked调用Win32 API。 不要使用Windows注册表。
它覆盖了。net 4.0,甚至包括了。net 4.5 api的一些特性,但是有一些领域我们选择不去实现,因为api被弃用了,新的替代品被创建了,或者范围太大了。以下api在Mono中不可用:
Windows Presentation Foundation Windows Workflow Foundation(两个版本都不是) 实体框架 标准Web服务堆栈的WSE1/WSE2“附加组件”
此外,我们的WCF实现仅限于Silverlight支持的内容。
检查特定项目的最简单方法是运行Mono Migration Analyzer (MoMA)。好处是它会通知Mono团队那些会阻止你使用Mono的问题(如果有的话),这让他们优先考虑他们的工作。
我最近在SubSonic上运行了MoMA,只发现了一个问题——对Nullable类型的奇怪使用。这是一个很大的代码库,所以覆盖率非常高。
Mono在一些商业产品和开源产品中得到了积极的应用。它在一些大型应用程序中使用,如维基百科和Mozilla开发者中心,并已在嵌入式应用程序中使用,如Sansa MP3播放器,并为数以千计的已发行游戏提供了动力。
在语言层面,Mono编译器完全符合c# 5.0语言规范。
推荐文章
- 我如何能使一个组合框不可编辑的。net ?
- .NET反射的成本有多高?
- 将流转换为字符串并返回
- IEquatable和重写Object.Equals()之间的区别是什么?
- 创建一个堆栈大小为默认值50倍的线程有什么危险?
- 选择Enum类型的默认值而无需更改值
- String与StringBuilder
- 远程主机强制关闭现有连接
- 为什么ReSharper想要使用'var'的一切?
- 如何检查一个对象是否为空?
- 删除后面的零
- 从c#读取Excel文件
- 未将相关DLL复制到Visual Studio中的构建输出文件夹
- 存储值为> 24:00:00的.Net Timespan的正确SQL类型是什么?
- 是否有一种使用Dapper调用存储过程的方法?