有人在大型或中型项目中使用过。net开源实现Mono吗?我想知道它是否已经为现实世界的生产环境做好了准备。它是否稳定、快速、兼容……足够用了吗?将项目移植到Mono运行时是否需要花费大量的精力，或者它是否真的足够兼容，只需要为微软的运行时编写代码就可以了?
当前回答
这里有几个场景需要考虑:(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点来表示改变光标闪烁速率。或者类似的垃圾。
其他回答
我们在一个需要在Linux上运行的项目中使用了它，但重用了我们在Managed c++中构建的一些。net库。我对它的成功感到非常惊讶。我们的主要可执行文件是用c#编写的，我们可以引用托管的c++二进制文件，没有问题。Windows和Linux之间c#代码的唯一区别是RS232串口代码。
我能想到的唯一大事件发生在大约一个月前。Linux版本有一个在Windows版本中看不到的内存泄漏。在做了一些手动调试之后(Linux上Mono的基本分析器没有多大帮助)，我们能够将问题缩小到特定的代码块。我们最终修补了一个解决方案，但我仍然需要找一些时间回去，找出泄漏的根本原因是什么。
对于公认答案的建议现在有点过时了。
The windows forms implementation is pretty good now. (See Paint-Mono for a port of Paint.net which is a pretty involved Windows forms application. All that was required was an emulation layer for some of the P-Invoke and unsupported system calls). Path.Combine as well as Path.Seperator to join paths and filenames. The windows Registry is OK, as long as you are only using it for storing and retrieving data from your applications (i.e. you can't get any information about Windows from it, since it is basically a registry for Mono applications).
不幸的是，对于我们正在构建的应用程序类型来说，Mono似乎还没有准备好投入生产。总的来说，我们对它印象深刻，对它在Windows和EC2机器上的性能印象深刻，然而，我们的程序在Windows和linux上都因垃圾收集错误而崩溃。
错误信息是:“GC中的致命错误:太多堆节”，这里是一个链接，其他人以略微不同的方式遇到这个问题:
http://bugzilla.novell.com/show_bug.cgi?id=435906
我们在Mono中运行的第一段代码是我们开发的一个简单的编程挑战……代码将大约10mb的数据加载到一些数据结构(例如HashSets)中，然后对数据运行10个查询。我们将这些查询运行100次以计算它们的时间并获得平均值。
在Windows上，代码在第55个查询时崩溃。在linux上它可以工作，但一旦我们转移到更大的数据集，它也会崩溃。
这段代码非常简单，例如，把一些数据放入哈希集，然后查询这些哈希集等，所有本机c#，没有不安全的，没有API调用。在微软CLR上，它从来不会崩溃，在巨大的数据集上运行1000次也很好。
我们的一个人给米格尔发了邮件，附上了导致问题的代码，还没有回复。：(
似乎很多人也遇到过这个问题，但没有解决方案——有人建议用不同的GC设置重新编译Mono，但这似乎增加了崩溃的阈值。
单核细胞增多症很好，但据我所知，它不稳定。它可以工作，但是当你给单一进程一个严肃的工作去做时，它就会出错。
TL;DR -如果你:
在多线程环境中使用AppDomains(程序集加载/卸载) 无法维持“听之任之”的模式 在流程运行期间偶尔经历重载事件
下面是事实。
我们在RHEL5和Ubuntu上使用mono-2.6.7 (.net v 3.5)，在我看来，它是由Novell构建的最稳定的版本。它有一个问题卸载AppDomains (segfaults)，然而，它失败非常罕见，到目前为止，这是可以接受的(由我们)。
好的。但是如果你想使用。net 4.0的特性，你必须切换到2.10版本。X，或者3。X，这就是问题开始的地方。
与2.6.7相比，新版本简直无法接受。我编写了一个简单的压力测试应用程序来测试mono安装。
它在这里，并附有使用说明:https://github.com/head-thrash/stress_test_mono
它使用线程池工作线程。Worker将dll加载到AppDomain并尝试做一些数学工作。有些工作是多线程的，有些是单线程的。几乎所有的工作都是cpu限制的，尽管有一些从磁盘读取文件。
结果不是很好。事实上，对于3.0.12版本:
sgen GC段错误几乎立即处理 带有boehm的Mono存活时间更长(从2到5小时)，但最终会出现段故障
如上所述，sgen gc不能工作(mono从源代码构建):
* Assertion: should not be reached at sgen-scan-object.h:111
Stacktrace:
Native stacktrace:
mono() [0x4ab0ad]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x2b61ea830cb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x2b61eaa74425]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x2b61eaa77b8b]
mono() [0x62b49d]
mono() [0x62b5d6]
mono() [0x5d4f84]
mono() [0x5cb0af]
mono() [0x5cb2cc]
mono() [0x5cccfd]
mono() [0x5cd944]
mono() [0x5d12b6]
mono(mono_gc_collect+0x28) [0x5d16f8]
mono(mono_domain_finalize+0x7c) [0x59fb1c]
mono() [0x596ef0]
mono() [0x616f13]
mono() [0x626ee0]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x2b61ea828e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x2b61eab31ccd]
对于boehm segfaults -例如(Ubuntu 13.04, mono从源代码构建):
mono: mini-amd64.c:492: amd64_patch: Assertion `0' failed.
Stacktrace:
at <unknown> <0xffffffff>
at System.Collections.Generic.Dictionary`2.Init (int,System.Collections.Generic.IEqualityComparer`1<TKey>) [0x00012] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:264
at System.Collections.Generic.Dictionary`2..ctor () [0x00006] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:222
at System.Security.Cryptography.CryptoConfig/CryptoHandler..ctor (System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00014] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/Crypto
Config.cs:582
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00013] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoCo
nfig.cs:473
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /home/bkmz/my/mono/mcs/class/corlib/System/Guid.cs:492
或者(RHEL5, mono从rpm这里取ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/vmas%3A/mono-centos5)
Assertion at mini.c:3783, condition `code' not met
Stacktrace:
at <unknown> <0xffffffff>
at System.IO.StreamReader.ReadBuffer () [0x00012] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:394
at System.IO.StreamReader.Peek () [0x00006] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:429
at Mono.Xml.SmallXmlParser.Peek () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:271
at Mono.Xml.SmallXmlParser.Parse (System.IO.TextReader,Mono.Xml.SmallXmlParser/IContentHandler) [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:346
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00021] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptog
raphy/CryptoConfig.cs:475
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/Guid.cs:483
at System.Runtime.Remoting.RemotingServices.NewUri () [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:356
at System.Runtime.Remoting.RemotingServices.Marshal (System.MarshalByRefObject,string,System.Type) [0x000ba] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:329
at System.AppDomain.GetMarshalledDomainObjRef () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/AppDomain.cs:1363
这两种失败在某种程度上都与AppDomains逻辑有关，所以，你应该在mono中远离它们。
顺便说一句，测试的程序在Windows机器上运行24小时，在MS . net 4.5环境下没有任何故障。
总之，我想说的是，谨慎使用单倍体。它从第一眼就能起作用，但无论何时都很容易失败。你会留下一堆核心转储和对开源项目的重大信心损失。
这实际上取决于您从. net框架中使用的名称空间和类。我有兴趣将我的一个windows服务转换到我的电子邮件服务器(Suse)上运行，但我们遇到了几个尚未完全实现的api的硬障碍。Mono网站上的某个地方有一个图表，列出了所有的课程及其完成程度。如果你的申请被覆盖了，那就去申请吧。
当然，像任何其他应用程序一样，在做出全面承诺之前要进行原型设计和测试。
我们遇到的另一个问题是授权软件:如果您引用的是别人的DLL，那么您就无法通过编写代码来绕过隐藏在该程序集中的不兼容性。
