22

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 ?

Daniel
  • 1,150
  • 2
  • 10
  • 20

7 Answers7

22

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

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Walter
  • 16,158
  • 8
  • 58
  • 95
15

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.

Quandary
  • 393
  • 3
  • 10
  • I've had no difficulty with Winforms support in Mono. Granted, the result is not exactly artwork, but that's because it's not running in Windows. – Robert Harvey Dec 24 '10 at 17:56
  • 3
    Note: entity framework is now open source. mono team started including it in current development version – linquize Aug 09 '12 at 14:02
  • @Robert Harvey: Grantet, much of the basics work (e.g. button, treeview, text-fileds, labels, even datagrids), but as soon as you add a splitter, it's "Not implemented exception". – Quandary Nov 18 '14 at 19:10
14

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

Adam Lear
  • 31,939
  • 8
  • 101
  • 125
  • Yes, you have to control which mono version to use. The one comes with linux distros is usually quite old so it has more bugs. We ship that from git mono-2-10 branch from time to time in order to reduce bugs and we know which possible bugs our program may suffer. – linquize Jun 03 '12 at 01:49
3

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.

Jon Hopkins
  • 22,734
  • 11
  • 90
  • 137
  • 3
    My understanding was that the CLR/C# spec is not proprietary and Mono implements that spec without much (if any) reliance on the original .NET source. – Adam Lear Dec 24 '10 at 16:54
  • 5
    @Anna: I may not be an expert on these things, but I am pretty sure that Mono is still at risk, regardless of how little reliance it has upon the original .NET source. This is because of Microsoft's patents (which can be enforced with or without Mono copying Microsoft's code). I think the FSF succinctly summarized the problem here: http://www.fsf.org/news/2009-07-mscp-mono – Adam Paynter Dec 25 '10 at 23:20
3

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

Mladen Jablanović
  • 1,267
  • 7
  • 10
  • 7
    One reason would be that C# is just a more mature, better designed language than Java and easier and more hassle-free to work with. That sounds like a *very* compelling reason to me. – Konrad Rudolph Dec 24 '10 at 22:37
  • 3
    @Konrad: That's true for recent C# versions (they started off about the same, but it evolves way faster than Java). Unfortunately, my experience tells me that enterprises rarely pick language on its merits. On the other hand, both .NET and JVM offer alternative languages, arguably better designed than both C# and Java, so I wouldn't really favor one over another based on that. – Mladen Jablanović Dec 25 '10 at 08:28
  • Had Mono been available earlier, we would have considered .Net/Mono for our environment. However, it wasn't, so now we're down the Java path. We may do some work in .Net/Mono, but the primary environment is Java and is expected to stay that way for quite some time. Being someone that works in both, I don't get the Java bashing from the C#ers. They're VERY similar. The C# language is *slightly* better, but the Java libraries and extra JVM languages are better. As platforms overall, they're very nearly equal. The library stuff is more important to me, so I might even give the nod to Java. – Brian Knoblauch Dec 22 '11 at 13:00
  • 1
    Mono allows to use C# in Linux. C# has so many syntactic sugar to facilitate development. – linquize Jun 02 '12 at 14:44
  • 2015: Java is a second class citizen on OS X (Mac). Mono works beautifully on OS X (though WinForms is still slow and ugly). And with OmniSharp, you can get all sorts of IDE-quality editing tools in non-IDE editors (Sublime, Atom, Vim, Emacs). – Kent A. Sep 02 '15 at 12:54
1

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:

  • Console App
  • Web App

Problems encountered:

  • WinForms not stable: crash randomly.
  • Language support: The community may not know every language well, especially the dialects for some countries/cities. Corresponding locales / collations may be missed.
  • Rarely used methods may have incompatible behaviour with .NET.
  • xsp only supports HTTP 1.0. Currently it lacks support HTTP 1.1.
  • Browser control does not work well.

It is better to use mono internally (such as ERP system) as a controlled environment.

linquize
  • 1,150
  • 1
  • 11
  • 20
0

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.

tylerl
  • 4,850
  • 21
  • 32