I played around with MonoDevelop 2.2 beta 1 on OS X a while ago.  Back then i considered it promising, yet unusable due to the fact that writing and editing code was extremely slow.  The Mono project recently released Mono 2.6 and a final MonoDevelop 2.2 release so i figured i’d give it another shot on OS X. 

Installation was yet again a breeze… you’re basically up and running within 5 minutes (depending on the speed of your internet connection for downloading the bits obviously).  And this time, the code writing/editing problems have been solved and you can indeed write code in it.  Instead of trying some silly example in it, i wanted to see if Agatha’s in-process Hello World example would work on Mono.   I downloaded the code, and opened the Examples solution:

This solution contains 2 Silverlight projects, 2 Web Application Projects, some regular .NET class libraries and 2 console projects.  MonoDevelop opened it all without any problems and seemed to recognize the different kinds of projects without problems:

While it may not seem impressive to you, i was glad to see that it correctly determined that the Agatha.Common.Silverlight project is indeed a Silverlight project instead of a regular .NET project.  Because the Agatha.Common.Silverlight needs to have some types that are also present in the Agatha.Common assembly, i used linked files in the Agatha.Common.Silverlight project to include those types in the Silverlight assembly.  MonoDevelop nicely picked up on that, and even seems to play more nicely with linked files than Visual Studio does:

After that i wanted to change the code formatting options to the settings that i prefer.  In the beta 1 version that i tried earlier, there were plenty of formatting options that you could change, but unfortunately it appears that they cut it from the final release:

This is very unfortunate because the number of settings that you can change for C# formatting is, as you can see, extremely limited.

Oh well, i was curious to see whether Agatha’s in-process Hello World example would work so i just started the Sample.ServiceAndClientInSameProcess console project.  Now, keep in mind that this in-process sample doesn’t use Silverlight, nor WCF, nor ASP.NET… it’s just a simple .NET process.  Unfortunately, it crashed:

Now, before people blame the Castle.MicroKernel code for this problem it’s important to remember that this code works without problems on Windows with Microsoft’s .NET runtime.   And that is basically the problem i’ve had with Mono every time i tried it for more than something trivial.  Code that works on Microsoft’s .NET runtime should behave exactly the same on Mono if they ever want to be a viable cross-platform .NET implementation.  Hell, even bugs in Microsoft’s .NET runtime should be duplicated, so i don’t care if there’s a bug in either Mono’s or Microsoft’s implementation of the ReaderWriterLock class.  Both implementations should behave the same and that’s all there is to it.

I still wanted to see it working on Mono, so i went to the part of the code that configures Agatha to use Windsor:

This isn’t the default color scheme that MonoDevelop uses, but it is one of the default schemes that ships with the IDE which is certainly a nice touch.

I just needed to change the last argument to the ServiceLayerAndClientConfiguration constructor to a new instance of Agatha.Unity.Container and then i could try it again.  Except that i still had to add a reference to the Agatha.Unity project to this console project.  So i opened the Edit References dialog and was very happy to see this:

I wasn’t happy because it’s a nice screen (which it isn’t) but because it showed up instantly.  And notice that it lists all of the assemblies that are present in the GAC, which for some reason works instantly on Mono yet takes ages to do in Visual Studio 2008.  I switched over to the Projects tab because i needed to select the Agatha.Unity project as a reference:

It’s nice to know that at least some developers can develop a reference-managing screen which enables you to manage your references in a fraction of the time it would take merely to load a similar screen in Visual Studio 2008, without having to resort to the workaround that will be used in Visual Studio 2010.

After that, the Hello World sample still didn’t work properly.  The output of the asynchronously sent request wouldn’t show in the console output but there were no exceptions being thrown either.  So i put a breakpoint in the request handler to make sure that it was at least being executed twice (once for the synchronous request, once for the asynchronous request):

I was glad to see the debugger actually break upon entering the breakpoint because that was one of the things that also didn’t work in the beta 1 release of MonoDevelop 2.2.  But anyways, it hit this breakpoint twice so both Hello World requests were indeed handled, yet the response for the asynchronous request didn’t make its way to the console output for some reason.  I added a breakpoint in the AsynchRequestDispatcher class to see if the response at least made its way into that part, and that’s when the debugging experience started to go wrong.  After stepping through a couple of lines of code, it just stopped debugging and ran through the code as if there was no more debugger attached.  I tried this a couple of times, always with the same result, except for 2 situations where the IDE would freeze, and the mono process holding both my CPU cores hostage at 100% usage.  After about 8 attempts, i just gave up.

The MonoDevelop project certainly has made some huge improvements since the last time i tried it (3 months ago), but this should not have been a final release.  Yes, you can finally write code in it.  Yes, you can debug it.  But no, it’s certainly not stable.  Debugging can lead to hard crashes.  Sometimes, the IDE doesn’t close properly and you have to kill the process.  There was one case where i lost syntax highlighting and intellisense in one method while it still worked in other methods.   Restarting MonoDevelop brought back the syntax highlighting and intellisense in that method.  I also ran into some UI glitches where the GTK treeview used in the solution explorer no longer wanted to expand its items.  I had to start clicking on other UI components before i could get the treeview to expand or collapse its items again.  Sometimes, button clicks didn’t seem to be registered immediately and i had to click a couple of times.  And no, it’s not a problem with my mouse since i don’t run into this with any other application.  Though MonoDevelop is the only GTK application that i’ve used on this machine.

But still, if you think about the considerable improvements that the MonoDevelop team has made in the past 3 months, the remaining issues should probably be easy tasks to finish.  Which makes it all the more frustrating that this final release seems to be rushed.  Hopefully, the next release will make it a truly usable IDE for .NET on OS X.

As for the Mono project itself… i find it troubling that i can’t run my code on their latest 2.6.1 release.  This is standard .NET code that runs perfectly fine on Microsoft’s .NET runtime and again, it should run exactly the same on Mono.  And i always seem to run into issues with this whenever i try Mono.  Yet at the same time, many people often claim that Mono is indeed a viable alternative for cross-platform .NET development.  I can’t help but wonder if those people only seem to try very trivial stuff, or if they are actively working around bugs in the Mono libraries.  I really want Mono to succeed, but so far, none of my attempts at running non-trivial .NET code on Mono have gone without problems.   And i’m willing to bet that i’m not the only one, because that certainly would be a very, very big coincidence.

As some of you already know, i’m a long-time Mac user. At work i obviously use Windows, but at home i only use Windows (through VMWare) when i want to code in Visual Studio. Other than that, i stay away from Windows as much as possible because i simply don’t like it. The recent MonoDevelop 2.2 beta release promises OS X support so i wanted to try it out.

Unfortunately, there is no integrated installer for both Mono and MonoDevelop, so you’ll need to download and install Mono separately. I used the stable 2.4.2 version which i downloaded here. After that, i downloaded and installed the 2.2 beta1 release of MonoDevelop here.

Installation is extremely quick and easy, so after a couple of minutes you have this on your screen:

Doesn’t really look like a typical OS X application due to the GTK+ usage, but we can live with that

I then wanted to create a new project:

There are some interesting project templates there (notice the iPhone and Moonlight options) but i just selected a regular console project. After doing so, you get some interesting packaging options for your project:

After that you can start working on your project:

I wanted to run it first to make sure everything was working:

I also wanted to try the integrated debugging so i put a breakpoint in the code:

Unfortunately, running it with the debugger (that icon isn’t shown in the screenshot because it’s not visible when you reduce the size of the window to the size shown in the picture) didn’t make it break on the breakpoint… it just showed the output as it does when not running with the debugger. I then looked in the solution options to see if i had to enable debugging or anything like that. Didn’t really find any debugging related settings (i was hoping for a ‘make it work’ checkbox or something like that) but i did see this:

You can set a few formatting options (obviously not as many as a Resharper user is used to) for your C# code, which is definitely a nice and important touch. Unfortunately i got the following exception when saving my changes:

A very nice addition here would be a button which allows you to automatically report the bug with its stackstrace to the MonoDevelop team. It would benefit both the developers and the users so i hope they will add this soon.

I also looked into some project specific settings and you’ll find plenty of familiar options there:

Alright, enough with the settings… let’s start coding! Once i added the new file, i was slightly disappointed with the unnecessary whitespace in the file:

Most people will just delete this every time anyway, so it would be better if empty classes were created with as little excessive whitespace as possible.

And then i started coding. Well, i tried to. The editor was unbearably slow on my Macbook. Ok, it’s not the fastest machine (Macbook 2.1, 2.16Gh Core 2 Duo and 3GB RAM) but it should definitely be capable enough to write and edit code in a usable manner. The editor would lag so much behind my typing that it was just completely unusable. It’s not because i type fast or anything, because it was unusable when typing slowly as well. After a couple of lines of code, i simply gave up. From what i did saw, it has simple code completion and intellisense support so that’s nice. But i really hope they can seriously speed up the editor soon.

All in all, i am hopeful that MonoDevelop on OS X will become a reasonably viable solution in the near future. It’s a simple IDE, nowhere near as powerful as Visual Studio (let alone one with Resharper) but it does have most of the important basics that you’ll need. At this point, i don’t consider it usable (after all, writing and editing code is fairly important) but i really hope that the MonoDevelop team will fix this soon. It would be very nice to be able to use this successfully on OS X.