Is Mono ready for prime time?

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?

Solution 1

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.

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.

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.

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

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.

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.

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

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.

Solution 2

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.

Solution 3

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.

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.

Either way, Mono is great, and stable.

Key things to remember when creating a cross platform program:

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

Solution 4

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.

Solution 5

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

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

View more solutions

Comments

[Corey]

> The Windows.Forms implementation is still a little buggy Do you know how good Mono 2.0 preview's support is for Windows Forms 2.0?

[Ferruccio]

That's the Mono Migration Analyzer for anyone scratching their head wondering what this has to do with the Museum of Modern Art.

[Andrei Rînea]

Miguel is at it again ;) Great work!

[Admin]

who does this guy think he is ? the creator of mono???!! ... o wait..

[Tim]

So how do you write code for serial ports that handles both? The whole point of CLR/Mono is to be platform independent, right? Is this done in config files?

[Drahcir]

Is there an equivalent to LINQ in mono? Because I am a .net developer and basically not using linux because of this issue (amongst others)

[JP Richardson]

That's really too bad. WPF is a decent UI toolkit.

[usr]

" things as useful as the changing the cursor blinking rate expressed as two bezier points encoded in BCD form in a wParam" lol

[Jared Updike]

Path.Separator is good advice, except Mono on OS X has ':', not '/'! Ha! That's the old Mac OS (<= 9.0) separator. Wha? Unix is / all the way.

[Evan Plaice]

Thank you so much for Mono...

[harpo]

+1 for the follow up... looks like this page may be out-of-date once again, though.

[Kris Erickson]

Yeah, two years is a lifetime in Mono with the speed that those guys work.

[Stefan Steiger]

Quite a fair and truthful answer, considering Miguel is the creator of mono. But while it'a accurate for asp.net, he isn't saying that even if winforms runtime is implemented and works correctly, most of the time it doesn't look/render good enough for selling your mono applications. You need to use GTK# for that. And support from the mono runtime isn't all. If some moron used windows path separators instead of system.io.path.directoryseparatorchar it won't work out of the box, and that goes for difference in filename upper-lower-cases, too. The last thing is especially true for 3rd party tools

[j03m]

To be fair, this question was posted in 08. Since then, I believe a lot has matured. There are also XNA ports and Monotouch which seem promising.

[David Schmitt]

miguel, it'd be nice to get an update on this post ;-)

[Christophe Debove]

can you tell me (if you can) what is the website you're talking about?

[Patrick McEvoy]

This is anecdotal evidence presented as fact and comes across to me as FUD

[Rui Marques]

Actually ASP.NET can be faster running under nginx/fast-cgi than on IIS. It all depends on what part of the framework is ported/well tested: mono-project.com/Compatibility. Must agree with @firegrass.

[Programmdude]

I don't bother with Environment.NewLine or Path.Separator, just use / and \n. Every desktop system currently in popular use(unless I am missing some), uses / and \n. Windows prefers \ and \r\n, but will happily use the unix ones.

[Amir Abiri]

It's worth bearing in mind that there is inherently a huge difference between desktop application and server-side code. If you have a REST API or some background web crawler or number cruncher chances are you can xcopy it right now to an Ubuntu server and run it.

[Amir Abiri]

This is one person's personal's experience presented as such. With the exception of prefixing it with "I think" it's a valid contribution to this discussion.

[MiKom]

Have you tried filing a bug in Xamarin bugzilla?

[head_thrash]

bugzilla.xamarin.com/show_bug.cgi?id=15064

[head_thrash]

bugzilla.xamarin.com/show_bug.cgi?id=16493

[Zameer Ansari]

@miguel.de.icaza Will .NET core eventually replace Mono in future?

[Wyatt Ward]

@JP Richardson I get what you're getting at - it's nice when programming - but I'd not call it "decent" if it's built from conception with the intention to be a non-portable toolkit.

[JP Richardson]

@Wyatt8740 my comment was written 10 years ago.

[Wyatt Ward]

@JP Richardson lol, my bad. But it still wasn't meant to be portable even ten years back.