.net Mono 准备好迎接黄金时段了吗？

Is Mono ready for prime time?

提问by wvdschel

Has anyone used Mono, the open source .NET implementation on a large or medium sized project? I'm wondering if it's ready for real world, production environments. Is it stable, fast, compatible, ... enough to use? Does it take a lot of effort to port projects to the Mono runtime, or is it really, reallycompatible enough to just take of and run already written code for Microsoft's runtime?

有没有人在大型或中型项目中使用过 Mono，开源 .NET 实现？我想知道它是否已准备好用于现实世界的生产环境。它是否稳定、快速、兼容、...足以使用？将项目移植到 Mono 运行时是否需要付出很多努力，或者它是否真的非常兼容，只需为 Microsoft 的运行时获取和运行已经编写的代码？

回答by miguel.de.icaza

There are a couple of scenarios to consider: (a) if you are porting an existing application and wondering if Mono is good enough for this task; (b) you are starting to write some new code, and you want to know if Mono is mature enough.

有几种情况需要考虑：(a) 如果您正在移植现有的应用程序并且想知道 Mono 是否足以完成这项任务；(b) 您开始编写一些新代码，并且想知道 Mono 是否足够成熟。

For the first case, you can use the Mono Migration Analyzer tool(Moma) to evaluate how far your application is from running on Mono. If the evaluation comes back with flying colors, you should start on your testing and QA and get ready to ship.

对于第一种情况，您可以使用Mono Migration Analyzer 工具(Moma) 来评估您的应用程序在 Mono 上运行的距离。如果评估结果出色，您应该开始测试和 QA 并准备发货。

If your evaluation comes back with a report highlighting features that are missing or differ significantly in their semantics in Mono you will have to evaluate whether the code can be adapted, rewritten or in the worst case whether your application can work with reduced functionality.

如果您的评估返回一份报告，该报告突出显示了在 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).

根据我们基于用户提交的 Moma 统计数据（这是来自记忆）大约 50% 的应用程序开箱即用，大约 25% 需要大约一周的工作（重构、适应），另外 15% 需要认真致力于重做你的代码块，其余的不值得费心移植，因为它们与 Win32 非常紧密地联系在一起。在这一点上，要么您从零开始，要么业务决策将推动使您的代码可移植的努力，但我们正在谈论价值数月的工作（至少从我们拥有的报告来看）。

If you are starting from scratch, the situation is a lot simpler, because you will only be using the APIs that are present in Mono. As long as you stay with the supported stack (which is pretty much .NET 2.0, plus all the core upgrades in 3.5 including LINQ and System.Core, plus any of the Mono cross-platform APIs) you will be fine.

如果您从头开始，情况会简单得多，因为您将只使用 Mono 中存在的 API。只要您使用受支持的堆栈（几乎是 .NET 2.0，加上 3.5 中的所有核心升级，包括 LINQ 和 System.Core，以及任何 Mono 跨平台 API），您就会没事。

Every once in a while you might run into bugs in Mono or limitations, and you might have to work around them, but that is not different than any other system.

每隔一段时间，您可能会遇到 Mono 中的错误或限制，您可能必须解决它们，但这与任何其他系统没有什么不同。

As for portability: ASP.NET applications are the easier ones to port, as those have little to no dependencies on Win32 and you can even use SQL server or other popular databases (there are plenty of bundled database providers with Mono).

至于可移植性：ASP.NET 应用程序更容易移植，因为这些应用程序对 Win32 几乎没有依赖性，您甚至可以使用 SQL 服务器或其他流行的数据库（有很多与 Mono 捆绑在一起的数据库提供程序）。

Windows.Forms porting is sometimes trickier because developers like to escape the .NET sandbox and P/Invoke their brains out to configure things as useful as the changing the cursor blinking rate expressed as two bezier points encoded in BCD form in a wParam. Or some junk like that.

Windows.Forms 移植有时会比较棘手，因为开发人员喜欢避开 .NET 沙箱并 P/Invoke 他们的大脑来配置一些有用的东西，例如更改光标闪烁率，表示为 wParam 中以 BCD 形式编码的两个贝塞尔点。或者一些类似的垃圾。

回答by Jon Galloway

It has pretty extensive coverage up to .NET 4.0 and even include some features from .NET 4.5 APIs, but there are a few areas that we have chosen not to implement due to the APIs being deprecated, new alternatives being created or the scope being too large. The following APIs are not available in Mono:

它对 .NET 4.0 的覆盖范围非常广泛，甚至包括 .NET 4.5 API 的一些功能，但由于 API 已弃用、创建了新的替代方案或范围太大，我们选择不实施一些领域大的。以下 API 在 Mono 中不可用：

• Windows Presentation Foundation
• Windows Workflow Foundation (neither of the two versions)
• Entity Framework
• The WSE1/WSE2 "add-ons" to the standard Web Services stack

• Windows 演示基础
• Windows Workflow Foundation（两个版本都没有）
• 实体框架
• 标准 Web 服务堆栈的 WSE1/WSE2“附加组件”

Additionally, our WCF implementation is limited to what Silverlight supported.

此外，我们的 WCF 实现仅限于 Silverlight 支持的内容。

The easiest way to check for your specific project is to run the Mono Migration Analyzer (MoMA). The benefit is that it will notify the Mono team of issues which will prevent you from using Mono (if any), which lets them prioritize their work.

检查特定项目的最简单方法是运行Mono Migration Analyzer (MoMA)。好处是它会通知 Mono 团队阻止您使用 Mono（如果有）的问题，这让他们可以优先处理他们的工作。

I recently ran MoMA on SubSonic and found only one issue - a weird use of Nullable types. That's a big codebase, so the coverage there was pretty impressive.

我最近在 SubSonic 上运行了 MoMA，但只发现了一个问题 - Nullable 类型的奇怪使用。这是一个很大的代码库，所以那里的覆盖范围非常令人印象深刻。

Mono is in active use in several commercial as well as open source products. It's in use in some large applications, such as Wikipedia and the Mozilla Developer Center, and has been used in embedded applications such as the Sansa MP3 players and powers thousands of published games.

Mono 在多个商业和开源产品中得到了积极的使用。它已在一些大型应用程序中使用，例如Wikipedia 和 Mozilla 开发人员中心，并已用于嵌入式应用程序，例如 Sansa MP3 播放器，并为数以千计的已发布游戏提供支持。

At the language level, the Mono compiler is fully compliant with the C# 5.0 language specification.

在语言层面，Mono 编译器完全符合 C# 5.0 语言规范。

回答by FlySwat

On the desktop side, Mono works great if you commit to using GTK#. The Windows.Forms implementation is still a little buggy (for example, TrayIcon's don't work) but it has come a long way. Besides, GTK# is a better toolkit than Windows Forms as it is.

在桌面端，如果您承诺使用 GTK#，Mono 效果很好。Windows.Forms 实现仍然有一些问题（例如，TrayIcon 不起作用），但它已经走了很长一段路。此外，GTK# 是一个比 Windows 窗体更好的工具包。

On the web side, Mono has implemented enough of ASP.NET to run most sites perfectly. The difficulty here is finding a host that has mod_mono installed on apache, or doing it yourself if you have shell access to your host.

在 Web 方面，Mono 已经实现了足够的 ASP.NET 来完美地运行大多数站点。这里的困难是找到一个在 apache 上安装了 mod_mono 的主机，或者如果你有对你的主机的 shell 访问权限，那么你自己做。

Either way, Mono is great, and stable.

无论哪种方式，Mono 都很棒，而且很稳定。

Key things to remember when creating a cross platform program:

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

• Use GTK# instead of Windows.Forms
• Ensure to properly case your filenames
• Use Path.Separatorinstead of hardcoding "\", also use Environment.NewLineinstead of "\n".
• Do not use any P/Invoked calls to Win32 API.
• Do not use the Windows Registry.

• 使用 GTK# 而不是 Windows.Forms
• 确保正确区分您的文件名
• 使用Path.Separator代替硬编码"\"，也使用Environment.NewLine代替"\n".
• 不要使用任何对 Win32 API 的 P/Invoked 调用。
• 不要使用 Windows 注册表。

回答by damageboy

I personally use Mono in a prime-time env. I run mono servers dealing with giga-bytes of udp/tcp data processing related tasks and couldn't be happier.

我个人在黄金时段环境中使用 Mono。我运行处理千兆字节的 udp/tcp 数据处理相关任务的单声道服务器，并且非常高兴。

There are peculiarities, and one of the most annoying things is that you can't just "build" your msbuild files due to Mono's current state:

有一些特殊性，最烦人的事情之一是由于 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 beenthe 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...

• MonoDevelop（IDE）有一些部分 msbuild 支持，但基本上会在简单的 hello-world（自定义构建任务、动态“属性”如 $(SolutionDir)、真实配置等等）之外的任何“真实”构建配置上工作-结束）
• xbuild应该是mono-supplied-msbuild-fully-compatible-build-system 甚至更可怕，所以从命令行构建实际上比使用 GUI 更糟糕，这是一种非常“非正统”的状态用于 Linux 环境的 union...

Once/During getting your stuff actually BUILT, you might see some wildernesses even for code that SHOULD be supported like:

一次/在实际构建您的东西期间，即使对于应该支持的代码，您也可能会看到一些荒野，例如：

• the compiler getting borked on certain constructs
• and certain more advanced/new .NET classes throwing un-expected crap at you (XLinq anyone?)
• some immature runtime "features" (3GB heap limit ON x64... WTF!)

• 编译器对某些结构感到厌烦
• 以及某些更高级/新的 .NET 类向您抛出意外的废话（XLinq 有没有人？）
• 一些不成熟的运行时“功能”（x64 上的 3GB 堆限制...WTF！）

but heaving said that generally speaking things start working very quickly, and solutions/workarounds are abundant.

但heaving 说，一般来说事情开始很快，解决方案/变通方法很丰富。

Once you've gone over those initial hurdles, my experience is that mono ROCKS, and keeps getting better with every iteration.

一旦你克服了这些最初的障碍，我的经验就是单声道摇滚，并且每次迭代都会变得更好。

I've had servers running with mono, processing 300GB of data per day, with tons of p/invokes and generally speaking doing LOTS of work and staying UP for 5-6 months, even with the "bleeding edge" mono.

我的服务器运行单声道，每天处理 300GB 的数据，有大量的 p/调用，一般来说，做大量的工作并保持 5-6 个月，即使是“出血边缘”单声道。

Hope this helps.

希望这可以帮助。

回答by Kris Erickson

The recommendations for the accepted answer are a little out of date now.

已接受答案的建议现在有点过时了。

• The windows forms implementation is pretty good now. (See Paint-Monofor 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).

• windows 窗体的实现现在非常好。（有关Paint.net 的一个端口，请参阅Paint-Mono，这是一个非常复杂的 Windows 窗体应用程序。所需要的只是一些 P-Invoke 和不受支持的系统调用的仿真层）。
• Path.Combine 以及 Path.Seperator 来连接路径和文件名。
• Windows 注册表是可以的，只要您仅使用它来存储和检索应用程序中的数据（即您无法从中获取有关 Windows 的任何信息，因为它基本上是 Mono 应用程序的注册表）。

回答by trampster

If you want to use WPF you'rr out of luck Mono currently has no plans to implement it.

如果您想使用 WPF，那么您很不走运 Mono 目前还没有实施它的计划。

http://www.mono-project.com/WPF

http://www.mono-project.com/WPF

回答by head_thrash

Well, mono is great, but as far as I can see, it is unstable. It works, but faults when you give mono process a serious work to do.

嗯，单声道很棒，但据我所知，它不稳定。它可以工作，但是当你给单进程一个严肃的工作时会出错。

TL;DR - Do not use mono if you :

TL;DR - 如果您：

• use AppDomains (Assembly Load\Unload) in multithreaded environments
• Can't sustain 'let-it-fail' model
• Experience occasional heavy-load events during process run

• 在多线程环境中使用 AppDomains (Assembly Load\Unload)
• 无法维持“让它失败”的模式
• 在流程运行期间偶尔遇到重载事件

So, the facts.

所以，事实。

We use mono-2.6.7 (.net v 3.5) on RHEL5, Ubuntu, and, to my point of view, it is most stable version built by Novell. It has an issue with Unloading AppDomains (segfaults), however, it fails very rare and this, by far, is acceptable (by us).

我们在 RHEL5、Ubuntu 上使用 mono-2.6.7 (.net v 3.5)，在我看来，它是 Novell 构建的最稳定的版本。它存在卸载 AppDomains（段错误）的问题，但是，它失败的情况非常罕见，到目前为止，这是可以接受的（我们）。

Okay. But if you want to use features of .net 4.0, you have to switch to versions 2.10.x, or 3.x, and that's where problems begin.

好的。但是，如果您想使用 .net 4.0 的功能，则必须切换到 2.10.x 或 3.x 版本，这就是问题开始的地方。

Compared to 2.6.7, new versions are just unacceptable to be used. I wrote a simple stress test application to tests mono installations.

与2.6.7相比，新版本是不能接受的。我编写了一个简单的压力测试应用程序来测试单声道安装。

It is here, with instructions to use : https://github.com/head-thrash/stress_test_mono

它在这里，有使用说明：https: //github.com/head-thrash/stress_test_mono

It uses Thread Pool Worker Threads. Worker loads dll to AppDomain and tries to do some math-work. Some of work is many-threaded, some is single. Almost all work is CPU-bound, although there are some reads of files from disk.

它使用线程池工作线程。Worker 将 dll 加载到 AppDomain 并尝试进行一些数学运算。有些工作是多线程的，有些是单线程的。尽管有一些从磁盘读取文件，但几乎所有工作都受 CPU 限制。

Results are not very good. In fact, for version 3.0.12:

结果不是很好。事实上，对于 3.0.12 版本：

• sgen GC segfaults process almost immediatly
• mono with boehm lives longer (from 2 to 5 hours), but segfaults eventually

• sgen GC 段错误几乎立即处理
• 带有 boehm 的单声道寿命更长（从 2 到 5 小时），但最终会出现段错误

As mentioned above, sgen gc just does not work (mono built from source):

如上所述， sgen gc 不起作用（从源代码构建的单声道）：

* 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]

As for boehm segfauls - for example (Ubuntu 13.04, mono built from source):

至于 boehm segfauls - 例如（Ubuntu 13.04，从源代码构建的单声道）：

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

Or (RHEL5, mono is taken from rpm here ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/vmas%3A/mono-centos5)

或者（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

Both failures are somehow connected to AppDomains logic, so, you should stay away from them in mono.

这两种失败都以某种方式与 AppDomains 逻辑有关，因此，您应该在单声道中远离它们。

BTW, tested program worked 24 hours on Windows machine in MS .NET 4.5 env without any fail.

顺便说一句，经过测试的程序在 MS .NET 4.5 环境中的 Windows 机器上运行 24 小时，没有任何失败。

So, in conclusion, I would like to say - use mono with caution. It works from the first glance, but can easily fail whenever. You'd be left with a bunch of core dumps and major faith loss in opensource projects.

所以，总而言之，我想说 - 谨慎使用单声道。乍一看它很有效，但无论何时都很容易失败。你会留下一堆核心转储和对开源项目的重大信心损失。

回答by Joe Shaw

MoMA is a great tool for this, as someone else suggested. The biggest sources of incompatibility these days are applications which DllImport (or P/Invoke) into Win32 libraries. Some assemblies aren't implemented, but most of them are Windows-only and really wouldn't make sense on Linux. I think it's fairly safe to say that most ASP.NET applications can run on Mono with limited modifications.

正如其他人所建议的那样，MoMA 是一个很好的工具。当今最大的不兼容来源是将 DllImport（或 P/Invoke）导入 Win32 库的应用程序。某些程序集未实现，但其中大多数仅适用于 Windows，并且在 Linux 上确实没有意义。我认为可以肯定地说，大多数 ASP.NET 应用程序只需进行有限的修改就可以在 Mono 上运行。

(Disclosure: I've contributed to Mono itself, as well as written apps that run on top of it.)

（披露：我为 Mono 本身以及在其上运行的编写的应用程序做出了贡献。）

回答by CHitchcock

We've been using it for a project here at work that needed to run on Linux but reuse some .NET libraries that we built in Managed C++. I've been very surprised at how well it has worked out. Our main executable is being written in C# and we can just reference our Managed C++ binaries with no issue. The only difference in the C# code between Windows and Linux is RS232 serial port code.

我们一直在将它用于需要在 Linux 上运行但重用我们在托管 C++ 中构建的一些 .NET 库的工作项目。我对它的效果感到非常惊讶。我们的主要可执行文件是用 C# 编写的，我们可以毫无问题地引用我们的托管 C++ 二进制文件。Windows 和 Linux 之间 C# 代码的唯一区别是 RS232 串口代码。

The only big issue I can think of happened about a month ago. The Linux build had a memory leak that wasn't seen on the Windows build. After doing some manual debugging (the basic profilers for Mono on Linux didn't help much), we were able to narrow the issue down to a specific chunk of code. We ended up patching a workaround, but I still need to find some time to go back and figure out what the root cause of the leak was.

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

回答by TheSmurf

In many cases, you can take existing code and just run it on Mono, particularly if you're porting an ASP.NET application.

在许多情况下，您可以使用现有代码并在 Mono 上运行它，尤其是在移植 ASP.NET 应用程序时。

In some cases, you may require whole new sections of code to make it work. If you use System.Windows.Forms, for example, the application won't work unmodified. Likewise if you use any Windows-specific code (registry access code, for example). But I think the worst offender is UI code. That's particularly bad on Macintosh systems.

在某些情况下，您可能需要全新的代码段才能使其工作。例如，如果您使用 System.Windows.Forms，则该应用程序将无法在未经修改的情况下运行。同样，如果您使用任何特定于 Windows 的代码（例如，注册表访问代码）。但我认为最严重的违规者是 UI 代码。这在 Macintosh 系统上尤其糟糕。