For enterprise windows-based solutions, .NET is the best choice sometimes. How is Mono looked at by the enterprises who have to use Linux (or rather prefer to use Linux) ? Assuming that the developers aren't a problem and they are familiar with .NET/Mono and other possible competitors such as Java.
Would a medium/large company run Mono on their servers as opposite to technologies such as Java? Do you know of any such company ?
We used it in the large corporation where I work. We didn't plan on it from the start of the project but it just worked out that way.
We had an internal project that we developed in .NET, once we got into UAT, the business owner wanted to open the app up to some customers as well as the internal staff. The majority of our external (DMZ) servers are Linux based and the Windows servers that are in the DMZ weren't a good fit (too close to capacity). Instead of buying new hardware someone suggested running the app on Mono. We spent a couple of days doing our own testing and then released the app to QA, then UAT. We had no issues.
If we had been given the requirement at the start of the project, we may not have chosen to write it in .NET, but this was one nice outcome to a very, very late requirement change. Now we're pretty confident that if it came up again we could successfully deploy to Mono (although I would think eventually we'd have to tweak some code, I think we just got lucky).
I haven't used mono commercially, but I use it privately, because I work in a Windows company, but privately am a Linux user (so I can reuse what I do at work).
Overall, I agree with Miguel de Icaza who says:
- 25 % of .NET applications work out of the box with mono
- another 25% can be made to work within a day or less
- further 25% can be made to work within a week
- The last 25% require a complete rewrite of the application (WinForms/COM)
Mono works fairly well, but there are some problems:
- VB.NET support only for .NET <= 2.0
- Windows authentication not implemented
- WPF not implemented
- WCF support incomplete
- Entity Framework not implemented and no plans to implement
- "ASP.NET Web Parts" not implemented
- No COM-interop support
- Sybase connection for version 15.5 (latest) doesn't work
- Bugs and incompleteness in the C# class library (e.g. XML was buggy in mono < 2.6)
- The Linux web-browser control requires GTK#
Then the minor problems:
- Windows Forms work, but aren't always rendered properly
- MonoDevelop can't design windows forms
- MonoDevelop 'step through' debugging doesn't really work
- Mono-Service crashes after 5 hours...
Form what I can say:
- WebServices function excellently
- If you run a WebApplication, it works fairly well (if it doesn't use WebParts).
- If you run WindowsForms, it won't always look very nice (to say the least).
- There is no working equivalent for Microsoft Reporting Service (FYIreporting is the closest thing to it, but it's slow, buggy and very incomplete, plus no activity since more than a year)
- You will experience problems if you need to create Word or Excel documents.
If you want to develop .NET on Linux
- You could develop ASP.NET there (debugging & step through works very badly)
- You can't really develop WinForms on Linux
- You need to use GTK# instead of WinForms
In other words:
- Mono has it's place in running web applications and WebServices and MailServers.
- But it's not viable to run WindowsForms applications, you need to write applications with GTK#
- It lacks a reporting solution and MS file format support (or working libraries therefore)
Edit (2015 update):
I wanted to add that by now, 'step through' debugging works excellently, and you can use MonoDevelop to develop web applications on Linux, even with nuGet dependencies. The problem with Excel and Word libraries is also gone, and entity-framework is now open-source. The rest is pretty much "as is" (don't know if mono-service is fixed, but I would hope so).
What has improved as well is that you can now have current packages for your distro, meaning you don't need to wait until the next release of, say Debian/Ubuntu, until you get the latest mono version (without having to compile them yourselfs). This is a major time-safer.
Also, with the release of Roslyn, VB.NET support should get a lot better in the near future.
My company develops a major mostly-.NET desktop application and releases Linux versions running on Mono, so I would say yes, there is definitely a place for Mono in enterprise Windows-based solutions.
We package Mono with the installation of our application, not requiring the users to install it separately (and this way we control the version, too).
I think the main concern many corporates would have is the license issues between Mono and Microsoft. My understanding is that while Microsoft have formally agreed that Mono can use the core .NET technologies, but outside that, including about of very commonly used stuff, is more of a grey area legally with Microsoft stating no firm position on it one way or the other.
That obviously leaves open the possibility that down the line they'll demand license fees or just sue for patent violation. It's unlikely that either would happen from the way they're behaving right now but most corporates don't like that sort of uncertainty, particularly not when it comes with potential liabilities and costs attached.
I don't think there's much space for Mono there:
Java is already established platform on Linux, with huge community and abundance of enterprise quality libraries and tools, both commercial and open-source. I don't see any reason to pick Mono over Java when starting new project targeting Linux (or Mac), unless there's some specific circumstance (see Walter's answer).
Before using mono, we have to ensure no hardcoded '\' for path string (use Path.Combine()) or "COM" prefix (simply accept string instead of integer) for serial port is in the program.
What works well:
Problems encountered:
It is better to use mono internally (such as ERP system) as a controlled environment.
Mono is a great alternative if you already have .NET code that needs to run on a cross-platform environment. Mono is used pretty extensively in the business world specifically to solve this very problem.
I would argue against using the existence of Mono as an excuse for starting a project with .NET that you know will need to be cross-platform. The reason for this is the lag between the state-of-the-art with .NET versus the development speed of Mono.
On the other hand, if you do intend to use Mono in a future project, I would caution you to target the Mono framework and run on .NET as a secondary alternative since Mono is largely a subset of the full .NET functionality.
