不，单核细胞增多症还不能胜任严肃的工作。我用f#在Windows上写了几个程序，然后在Mono上运行。这些程序相当密集地使用磁盘、内存和cpu。我看到在单库(托管代码)中崩溃，在本地代码中崩溃，在虚拟机中崩溃。当mono运行时，程序比Windows中的。net慢了至少两倍，并且占用了更多的内存。在严肃的工作中远离单核细胞增多症。

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

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

这实际上取决于您从. net框架中使用的名称空间和类。我有兴趣将我的一个windows服务转换到我的电子邮件服务器(Suse)上运行，但我们遇到了几个尚未完全实现的api的硬障碍。Mono网站上的某个地方有一个图表，列出了所有的课程及其完成程度。如果你的申请被覆盖了，那就去申请吧。

当然，像任何其他应用程序一样，在做出全面承诺之前要进行原型设计和测试。

我们遇到的另一个问题是授权软件:如果您引用的是别人的DLL，那么您就无法通过编写代码来绕过隐藏在该程序集中的不兼容性。

它覆盖了。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语言规范。

不幸的是，对于我们正在构建的应用程序类型来说，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，但这似乎增加了崩溃的阈值。

我个人在黄金时段使用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。

希望这能有所帮助。