Wanted: user experiences with C# (mono) on MacOS and Linux

I have a friend who is was a serious Linux developer but now he's working with C# on Windows and is really loving it. I'm attracted to C# because, like Java, I should be able to compile on one system and run anywhere.

If you are developing on Windows with C#, you're using dot-开发者_运维技巧Net. On Linux and MacOS, you're using Mono.

Other people have posted that Mono is pretty good, no longer a science project, and that most of the core Microsoft functionality is present. But that's not really getting at the questions that I have. I'm wondering:

1. How does performance of Mono on Linux/MacOS rate against Java? If I want to run fast on all three platforms with the same object code, what's my best choice?
2. Is it easy/possible/reasonable to use Mono with makefiles and do my development with emacs?
3. Is there support for code factoring in MacOS and Linux, or am I better off just biting the bullet and doing all of my development in Windows?
4. How well does Mono work with Subversion and the rest of the open source development stack? How about autoconf? Or is this a completely different way of doing things?

Thanks

I have been using Mono on Linux for about three years and lately have been using it on OS X. Some of the Linux stuff was pretty extensive but the OS X stuff has just been some simple ASP.NET MVC2 apps so far.

1) Performance of Mono has never been an issue for me. That is not to say that performance has not been important, it is just that the performance of Mono itself has never been an issue. A lot of what I have done is web based so I/O and database memory use have hit me before Mono has.

Historically, the biggest deficiency with Mono has been the Garbage Collector (GC). I would say that Java is better tuned in this regard. The most recent versions of Mono have made huge strides in this area but I do not have any hard numbers for you in terms of comparisons.

I am sure Mono is faster sometimes and Java sometimes but I would say that Java is faster overall.

2) You can certainly do Mono development with makefiles. Certainly the Mono team itself does. Also you can certainly use Emacs and there is a C# mode for it.

I tend to use MonoDevelop and xbuild (Mono version of msbuild) myself and do not have any experience doing C# work in Emacs. MonoDevelop is great because it is exactly the same on all platforms. Also, although I rarely use it anymore, it is nice that the project format is the same as Visual Studio and SharpDevelop.

3) MonoDevelop has pretty decent code factoring support. It is the same on Windows, Linux, and Mac. You do not need to use Windows for development (though you certainly can) but I believe you will be happier using an IDE like MonoDevelop. Even things like Intellisense become hard to live without once you are used to them. But integrated debugging, being able to drill-down into the framework, database integration, unit testing, SCM integration, and other nice tooling support all in one place is just the way to go (for me at least).

4) Mono itself does not care about version control of course. Your source files are just text and you could use anything to manage them.

That said, MonoDevelop has fantastic Subversion support built right into the IDE. I have used it extensively and it is one of the reasons I have trouble moving off MonoDevelop even on Windows. The latest version of MonoDevelop (2.6 beta) includes Git support as well.

You did not mention unit testing but MonoDevelop also has NUnit support built into the IDE. I use that on every project as well and it works excellently. The version in MonoDevelop is 2.4.8 (if memory serves) so it is not quite current but it works great.

In a nutshell, Mono works really well with Open Source tooling in general. It has always played really well for me.

Autoconf is of course used by the Mono project itself but, as a Mono developer, I have never seen a need for it. I strive to only use managed code in my projects. As such, all I need on the target platform is Mono (or .NET). Not having to worry about all that stuff is one of the primary benefits of a managed environment like Mono or Java. The runtime itself (the CLR) ensures that my app has everything it needs to function properly.

I know that MonoDevelop will build autoconf/autorun files for C/C++ projects (non-Mono) but I have not done much with it myself.

As to a previous comment, the Mono JIT is obviously tuned to the target platform. That is where platform specific performance tuning happens.

Just as a comment, I find that Mono is best viewed as a development environment in it's own right rather than a compatibility layer for Microsoft stuff. The Mono team has extended .NET in many interesting ways. Anything you develop for Mono will run on .NET but there are some .NET features not available for Mono. For example, Mono does not support Windows Presentation Foundation (WPF). You have to use Windows Forms or GTK# for cross-platform GUI work. You can also use something like Cocoa# or MonoMac on the Mac, MonoTouch on iPhone, or MonoDroid for Android. You can use Moonlight instead of Silverlight as well although I have not played with it much.

One more thing since you asked about Java. I have found a few times that the Java world had libraries that I could not find equivalents for in the .NET world. In these cases, I have had amazing luck using IKVM.NET to integrate this into my Mono apps. IKVM.NET also works on .NET but Mono and IKVM.NET are very cozy and even share some code.

So there you go, one real answer for you at least.