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.
