Mono 2.0: .NET goes non-Windows

[dhilipkumar]

For some time now, the Novell-sponsored Mono Project has brought .NET to non-Microsoft platforms. Unfortunately, Mono has been quite far behind the .NET Framework and CLR. This all changes with the release of Mono 2.0 .

Three days before the 6 October 2008 release of Mono 2.0, I had the chance to speak with Miguel de Icaza, VP of Development Platforms and a founder of Mono, and Joseph Hill, product manager at Novell.

Mono 2.0 is API complete in regards to .NET 2.0; this means that Windows Forms applications and ASP.NET applications will both work within it. Additionally, many of the new features in .NET 3.5, including C# 3.0 and .NET Language-Integrated Query LINQ, are included. Miguel told me that implementing C# 3.0 was both fun and challenging and that getting the lexical closures right was "probably one of the hardest parts to implement" (which is not surprising at all). However, the big frameworks from .NET 3.0, such as Windows Presentation Foundation (WPF) and Windows Communication Foundation (WCF), are not included. There is an implementation of the Parallel Extensions Library. Because Microsoft's currently in CTP, Novell is not shipping its version with Mono 2.0, although it is available for download. And because Microsoft open sourced the DLR, IronPython and IronRuby will both work under Mono.

In terms of using code in Mono, no recompile is needed, although there is a C# compiler included. Because compiled .NET assemblies are in Microsoft Intermediate Language (MSIL), Mono acts as an MSIL interpreter like the .NET CLR. For web applications, the Mono Project has produced both an Apache plug-in and a FastCGI binding to allow it to hook into your web/application server. Mono works on a huge number of platforms, including Linux, Solaris (including SPARC platforms), Mac OS X, Windows, the Nintendo Wii (yes, you read that right), and BSD. In the case of BSD, you will need third-party patches to make it work; for all other platforms, Mono will work right out of the box and be running your .NET code. A recent version of Linux is needed (about three - four years old at most), since it uses some newer kernel features. On the Mac OS X platform, it includes Cocoa# for building native OS X applications in .NET. They also offer a pre-made VMware virtual machine with SuSE Linux and Mono installed for free.

They have also included a Mono migration analysis tool that will let you know if you are making calls that will work differently under Mono. Some .NET calls that access the Windows API mechanisms or low-level system calls will still work just fine, but the developer needs to keep in mind that the support is emulated or imitation -- it's not actually accessing the underlying mechanism. For example, accessing the registry is possible, but Mono creates a file-backed emulation of the registry and can only provide data that your application has stored in it to begin with. Something like trying to enumerate the NICs in the PC from the registry data will fail because those keys simply do not exist. You can also send the tool's output to Novell to get feedback on it.

From these reports, Miguel guesstimated that 45 per cent of applications work with zero lines of code that need to be changed. About 17 per cent have 1 - 20 statements that need to be changed (this is typically about a week's worth of effort). Another 20 per cent have 20 - 100 calls to be changed (this is usually around two - four months' worth of work). The remainders of the applications they see require too many changes to make it practical to put them on Mono. Miguel says that the performance is about 80 per cent of that of the .NET CLR on average. Some statements run faster, some run slower. He also mentioned that web applications often run faster in Mono than they do under the .NET CLR, because much of Mono's slowdowns occur in the GUI portion of the system.

For developers who want an alternative to Microsoft Visual Studio, there is Mono Develop. A new version of Mono Develop is slated for release in January 2009; it will deliver improved usability and an enlarged feature set, including support for Visual Studio file formats. This will allow developers on the same team to use both Mono Develop and Visual Studio, with no conversions between the two needed.

Overall, Mono 2.0 sounds really good. In the near future, I will try it out and let you know what I think.