Should I use Mono on a real project?

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?


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.


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


    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.

    链接地址: http://www.djcxy.com/p/52206.html

    上一篇: Mono对于严肃的企业发展足够强大吗?

    下一篇: 我应该在真正的项目中使用Mono吗?