有人在大型或中型项目中使用过。net开源实现Mono吗?我想知道它是否已经为现实世界的生产环境做好了准备。它是否稳定、快速、兼容……足够用了吗?将项目移植到Mono运行时是否需要花费大量的精力,或者它是否真的足够兼容,只需要为微软的运行时编写代码就可以了?


当前回答

在桌面端,如果您承诺使用gtk#, Mono工作得很好。窗户。表单实现仍然有一些bug(例如,TrayIcon的不能工作),但它已经取得了很大的进步。此外,gtk#是一个比Windows窗体更好的工具包。

在web端,Mono已经实现了足够多的ASP。NET可以完美地运行大多数网站。这里的困难是找到一个在apache上安装了mod_mono的主机,或者如果你有shell访问你的主机,你自己做。

不管怎样,Mono都很棒,而且很稳定。

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

使用gtk#而不是Windows。形式 确保文件名的大小写正确 使用路径。分隔符而不是硬编码“\”,也使用环境。换行,而不是“\n”。 不要使用任何P/Invoked调用Win32 API。 不要使用Windows注册表。

其他回答

我个人在黄金时段使用Mono。 我运行单服务器处理千兆字节的udp/tcp数据处理相关任务,不能再高兴了。

有一些特殊之处,其中最烦人的事情之一是,由于Mono的当前状态,你不能“构建”你的msbuild文件:

MonoDevelop (the IDE) has some partial msbuild support, but will basically bork on any "REAL" build conf beyond a simple hello-world (custom build tasks, dynamic "properties" like $(SolutionDir), real configuration to name a few dead-ends) xbuild which SHOULD have been the mono-supplied-msbuild-fully-compatible-build-system is even more horrible, so building from the command line is actually a worse experience than using the GUI, which is a very "unorthodox" state of the union for Linux environments...

一旦/在你的东西真正构建的过程中,你可能会看到一些应该支持的代码的荒野:

编译器在某些构造上出错 一些更高级的/新的。net类向你抛出意想不到的垃圾(XLinq的人吗?) 一些不成熟的运行时“特性”(3GB堆限制在x64…WTF !)

但heaving表示,一般来说,事情很快就会开始起作用,而且解决方案/变通方法很多。

一旦你克服了这些最初的障碍,我的经验是,mono很摇滚,并在每次迭代中变得越来越好。

我有使用mono运行的服务器,每天处理300GB的数据,有大量的p/调用,通常来说要做大量的工作,并且保持5-6个月,即使使用“最先进的”mono。

希望这能有所帮助。

我们在一个需要在Linux上运行的项目中使用了它,但重用了我们在Managed c++中构建的一些。net库。我对它的成功感到非常惊讶。我们的主要可执行文件是用c#编写的,我们可以引用托管的c++二进制文件,没有问题。Windows和Linux之间c#代码的唯一区别是RS232串口代码。

我能想到的唯一大事件发生在大约一个月前。Linux版本有一个在Windows版本中看不到的内存泄漏。在做了一些手动调试之后(Linux上Mono的基本分析器没有多大帮助),我们能够将问题缩小到特定的代码块。我们最终修补了一个解决方案,但我仍然需要找一些时间回去,找出泄漏的根本原因是什么。

你知道Mono 2.0预览版对Windows Forms 2.0的支持有多好吗?

从我使用它的一小部分来看,它似乎相对完整,几乎可用。它只是在一些地方看起来不太对,总的来说还是有点命中或错过。说实话,它和我们的一些表格一样好用,这让我很惊讶。

请查看www.plasticscm.com。所有东西(客户端、服务器、GUI、合并工具)都是在mono上编写的。

我可以想象,如果你有一个带有一些第三方组件的应用程序,你可能会被塞满。我怀疑很多供应商会在开发过程中考虑到Mono

例如:http://community.devexpress.com/forums/p/55085/185853.aspx