[.net] Is Mono ready for prime time?


7 Answers

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:

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

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

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.

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.

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.

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

Question

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, really compatible enough to just take of and run already written code for Microsoft's runtime?




Just check www.plasticscm.com. Everything (client, server, GUI, merge tools) is written on mono.




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.

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:

  • 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...

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!)

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

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.

Hope this helps.




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.

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







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.

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.




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 ;)

A large portion of the secret of supporting Mono I think is to use the right tools from the beginning, e.g. ActiveRecord, log4net, ra-ajax etc...







Related