Should I use Mono on a real project?

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?

Answer 1

I've used it for a number of internal and commercial projects with great success. My warnings:

• Write lots of unit tests and make sure they ALL pass under Mono -- this will save you a lot of trouble.
• Unless you absolutely have to, do NOT use their embedding API. It's damn easy to use, but it's ungodly easy to garbage collect valid memory or leak all of your memory.
• Don't ever, ever, ever even come close to SVN and unless there's no choice, do not compile your own. Things change so often in SVN that it's highly likely you'll end up implementing something that doesn't work on a release version if your project is significantly large.
• Don't try and figure out problems on your own for long, use the IRC channel. The people there are helpful and you'll save yourself days upon days -- don't make the same mistake I did.

Good luck!

Edit: The reason I say not to compile your own from source (release or SVN) is that it's easy to configure it differently than release binaries and hide bugs, for instance in the garbage collection.

Edit 2: Forgot to answer the second part to your question. In my case, I had no issues with porting code, but I wasn't using any MS-specific libraries (WinForms, ASP.NET, etc). If you're only using System.* stuff, you'll be fine; beyond that, you may run into issues. Mono 2.0 is quite solid, though.

Answer 2

I haven't used Mono myself but you may be interested to know that FogBugz uses Mono to provide Lucene.NET on Linux platforms. (I only know this because Joel mentioned it in passing in Stack Overflow Podcast #24.)

Answer 3

If you are doing ASP.NET 2.0 work, it works very well. Winforms may work, but it can cause display issues. If you want compatibility in a forms app, I would suggest GTK#, as it is crossplatform.

Like suggested, as long as you thouroughly test, I would agree to using it commercially if that is a viable option for you, unless it is winforms you need. In my opinion, i would stay away from it for now. And forget WPF as there is no support at this time, and there may never be (although they are working on moonlight, aka silverlight for linux)

Answer 4

I find Mono to be mostly binary compatible with MS. Hence I simply compile with MS, and run anywhere, like Java is meant to be!

The performance of Mono on Linux is getting very close to MS, as little as 2 times slower in some cases, vs 5-10 times slower when running Mono on Windows (but you should really stick to MS then).

Answer 5

I've got a bunch of shell apps in production.

I agree with @cody-brocious, write a lot of unit tests. I found in the past that Regular Expressions didn't work exactly the same way as the windows CLR.

It's actually simplier than you think to get into, just compile and run. If you use NAnt on your projects its even easier to transition.

I typically install mono from the source releases and I haven't had any problems.

Answer 6

I've used it for encryption/decryption tools and it worked fine.

In the future, I would consider using Mono/C#, but I would not expect it to be 100% exactly like .Net on Windows.

Answer 7

Of course, you can, especially after Mono 2.0 has been released. Mono 2.0, is ready for real projects.

You can check this

Answer 8

I had some experience with Mono.

Pure .NET stuff (like business logic, controllers or algorithms) can be ported without any problems. Yet, weird things start showing up in the components that interact with operating system, UI, services or persistence. So be prepared for some debugging and hacking.

Things that might help:

• Component-Driven Development - so that code is reused by Windows .NET and Mono, while differences are isolated and tested)
• Continuous Integration running and checking everything against Mono and MS.NET, so that possible issues could be discovered as fast as possible (automated deployment and sanity checks are also recommended)
• There are not a lot of UI component suites for shell development in Mono.
• When a component vendor says that his code is "compatible with Mono", it is not same as "runs on Mono and is supported".

Although in the present, there are some companies going into production with Mono, I'd still wait before rushing in there due to:

• Lack of decent and commercially supported UI component suites
• Issues with efficient garbage collection
• Not the best debugging experience (compare with the historical debugger in VS 2010)

PS: if there is a company offering fully managed cloud computing solution (not just a VM, but more like Hadoop equivalent for .NET), then I'll be forced to jump in despite these issues.