Yes it definitely is (if you're careful though) We support Mono in Ra-Ajax (Ajax library found at http://ra-ajax.org) and we're mostly not having problems at all. You need to be careful with some of the "most insane things" from .Net like WSE etc, and also probably quite some few of your existing projects will not be 100% Mono compatible, but new projects if you test them during development will mostly be compatible without problems with Mono. And the gain from supporting Linux etc through using Mono is really cool ;)

我认为支持Mono的很大一部分秘密是从一开始就使用正确的工具，例如ActiveRecord, log4net, ra-ajax等。

MoMA是一个很好的工具，就像其他人建议的那样。目前最大的不兼容性来源是将DllImport(或P/Invoke)导入Win32库的应用程序。有些程序集没有实现，但大多数程序集仅适用于windows，在Linux上确实没有意义。我认为可以肯定地说，大多数ASP。NET应用程序可以在Mono上运行，只需进行有限的修改。

(披露:我为Mono本身做出了贡献，也编写了在Mono上运行的应用程序。)

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

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

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

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

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

在许多情况下，你可以获取现有的代码并在Mono上运行，特别是如果你正在移植一个ASP。网络应用程序。

在某些情况下，您可能需要全新的代码段才能使其工作。如果你使用System.Windows。例如，如果不修改表单，应用程序将无法工作。同样，如果您使用任何特定于windows的代码(例如，注册表访问代码)。但我认为最糟糕的是UI代码。这在麦金塔系统上尤其糟糕。

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

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

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

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

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