Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For Production

Would you rather use Wine or Mono to run a .net application on Linux OpenSuse 11.

share|improve this question
Neither, I'm afraid. – Kyle Hodgson Aug 5 '09 at 13:21
Likewise; unless there was a really compelling reason why it absolutely HAD to be Linux I'd just run it on Windows. – Le Comte du Merde-fou Aug 5 '09 at 14:08
You guys should turn your comments into answers so I can downvote accordingly. Wine is fine and Mono is bono... – Peter Turner Aug 5 '09 at 14:10
up vote 5 down vote accepted

The base install for Wine doesn't have a .net runtime so I'd go with Mono.

share|improve this answer
+1. If your application is a console one, no problem as Mono has a nearly full implementation of the ECMA standards. For a GUI application, if it is pure managed, then again no problem. – Laurent Etiemble Dec 15 '09 at 13:35

In the stackoverflow podcast #61 , one of the main developers, Miguel de Icaza, states that mono is ready for production and says it is used being used in production. They also mention a visual studio plugin in the podcast that helps make sure the application is ready for Mono. In this stackoverflow post, they feel mono is ready for production as well.

I have never heard such claims made about Wine for .NET. So I would go with Mono.

share|improve this answer

Given the fact that Mono is able to run the application natively, I'd go for Mono. Support-wise, this is probably the better option, too. Otoh, if the .Net application uses Microsoft .Net specific parts of the specs (the patented stuff there is so much commotion about), you have no other choice but to use Wine. I don't even know whether that is possible though.

share|improve this answer

Is there a reason it has to be one of those two? Both are relatively mature. But it depends on the application, so you'd have to actually install and configure them with the application in question to see what the performance and compatibility is for each. Mono may run just hunky dory for most things but your application may have that one bit of functionality or find that one glitch that suddenly makes it crawl or crash. Ditto for Wine.

I'd explore virtualization as a possible solution as well; running the app in Virtualbox on a workstation, or VMWare ESXi or Xen on appropriate systems in a "native" environment will ensure compatibility (if it's a workstation application you could even run it in a seamless mode so it looks like just another application).

If you can give some background on the application in question it may help.

share|improve this answer

Given that Mono is a Novell project and Novell owns SUSE, you can count on good performance and support for Mono via OpenSUSE. Based on my experiences, Mono does a very good job implementing the CLR with a couple of library exceptions. As there are fewer layers of abstraction between running .NET code via Mono than running anything Windows-based via WINE, I would definitely use Mono.

One question I would have, however, is whether this is a custom app or a prepackaged app. If the former, it will be relatively easy to ensure full Mono compatibility (and you may want to build the app using MonoDevelop to get a heads-up although apps built with Visual Studio should run just fine). If the latter, you may want to see whether it has a history with Mono (some things, like Telerik, are certified to run well via Mono) or whether it is likely to use library (such as the MS DirectoryService pieces) that could present issues.

share|improve this answer

Slightly off-topic, but try taking a look at the Mono Migration Analyzer, MoMa.

MoMa is a tool you can use to test if an application would run under Mono and, if not, highlight the areas causing problems. MoMa works on both Windows and Linux and is very easy to use.

I have only used it once, but it was an easy way to see if an application would run or not.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.