Hands on with Mono 2.2

In October 2008, I wrote about the release of Mono 2.0 (an open source version of the .NET CLR and Framework that runs on many platforms including Windows, Linux, Solaris, and Mac OSX).

Since then, I've spent time with the application and, along the way, discovered that Mono is now up to version 2.2. I'm really grateful that I waited, too… the differences between 2.0 and 2.2 are pretty important.

I did all of my testing with the Mono Project's pre-made openSUSE VMware image. I tried working with three applications, all of which are Windows desktop applications. Application A and Application B are written entirely in C#, and Application C is written in VB.NET with a few classes in C#.

Applications A and B are small utility-type applications. Application A simply goes through all of the files in a directory (and its subdirectories) and attempts to open the file and read from it, and optionally tries to edit the file's properties (flipping the "read only" flag twice). Application B is a system tray application that maintains a list of directories to periodically check and make sure that the total size of the files in them are within certain boundaries. Application C is the photo mosaic software that I occasionally tinker with to demonstrate various concepts, particularly parallel processing.

At first, I tried to simply open my already compiled executables in the openSUSE GUI by double clicking the EXE files; not too surprisingly, the executables did not run. Next, I opened the Visual Studio projects in the Mono Development Environment (MDE), an IDE for working with Mono. From there, I was able to compile and run my applications.

What I should have done before that was put my applications through the Mono Migration Analyzer (MoMA). MoMA inspects an application to look for things that you should know about. Applications A and C got a clean bill of health, but Application B had one flagged function. However, Application C had a different problem: It uses the Microsoft Parallel Extensions Library (PFx).

Because PFx is still in CTP status, the Mono Project does not distribute its version of it with the default installation of Mono. One thing I noticed is that Application B had more warnings from MoMA in the 2.0 release, for a total of four. Clearly, many of the items on the "To Do" list in 2.0 were completed by the time 2.2 was re-released.

When I tried to run the applications, Application A ran flawlessly. Applications B and C, as expected, did not run. Application B compiled, but blew up when it tried to execute the line of code that MoMA flagged. Application C did not compile at all due to the missing library.

Unfortunately, what prevented Application B from working seemed to be something trivial, but it turned out to be a major hassle. I had a DataGridView control bound to a DataSet object, and the application blew up when it tried to get the enumerator from the DataViewManager component. An Internet search showed that the only results for this problem were a bug ticket submitted in 2008.

Needless to say, I was extremely displeased. Data bound controls are extraordinarily common in the .NET world. I am sure that if I was writing code for Mono to begin with, I would have expected this and not used the data bound control, but it is disappointing all the same.

For writing and debugging code, the MDE is barely adequate. The version in Mono 2.0 was one step up from a language-aware text editor; it did not support debugging at all. The version in Mono 2.2 is substantially improved. It has rudimentary visual debugging tools, but it is lacking something very important: a visual designer. Unless you don't mind writing all of the layout code by hand, you will need to use something other than MDE, which means using Visual Studio and importing your work into MDE.

Overall, I am impressed and disappointed with the Mono experience. What impresses me about it is the very existence of the project (and the tools) and just how far they have come. It is no small feat to try to redo Microsoft's work with the .NET Framework. On the other hand, it is disappointing that Mono still has such a long way to go before it is a functional equivalent (or at least a functional competitor) to Microsoft's .NET implementation.

In its current form, I feel that Mono is usable, but you would need to have staff experienced in Mono development in order to avoid the various shortcomings. If you are writing an application that is designed to work on many platforms, Mono is still an alternative, but be aware that it is not a simple matter of "recompile and deploy" in many cases.

Disclosure of industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides. He is an employee of Levit & James, Inc. in a multi-disciplinary role that combines programming, network management, and systems administration and has been blogging at TechRepublic since 2005.