Now at version 1.2, Mono has expanded its Microsoft API stack so that Windows developers can port .Net applications to Linux without changing a single line of code. Mono developers hope that by the third quarter the Mono framework can get up to speed with Microsoft's current .Net 3.0. They also plan to include the new Windows Vista communication foundation APIs.
However, there is a lot of work that still needs to be done. Mono's .Net 2.0 APIs are still limited and primarily cover Generic types, XML, ASP.Net 2.0, ADO.Net 2.0, networking and Windows.Forms. Even with this extensive coverage, developers are still forced to test the code or find workarounds because the framework is not complete.
What's a runtime environment without a compiler? Mono developers have an answer for that, too, by including a C# compiler and a new debugger. In addition, Mono supports Gtk#, which is a binding for Gnome on Linux. Mono also supports WinForms, Web services and ASP.Net.
The WinForms is an awesome attempt to build controls in managed code using Microsoft's System.Windows.Forms framework structure. Do not port WinForms-based applications just yet, however; the WinForms API is still far from complete.
Microsoft's licensing of the C# language and its submissions to the European Computer Manufacturer's Association (ECMA) have made it possible for Mono developers to reconstruct the Common Intermediate Language and formulate its bindings and operations. The result has been phenomenal. Mono's gmcs compiler follows C# 2.0 language and supports most of the 2.x features such as Generics, partial classes, friend assemblies and fixed buffers.
By contrast, Mono's debugger is still a raw product. CRN Test Center engineers highly recommend reading through the debugger documentation and carefully reviewing the classes that are supported by Mono's framework before embarking on a migration. The debugger is currently dependent on the GDB, Valgrind and the runtime itself to produce output.
A word of advice: Get used to the Linux command line when debugging code. Because handling thread exceptions is extremely difficult, engineers do not recommend using the .Net threading mechanism until there is a 1.0 version of the debugger.
Fortunately, Mono does not need to be experienced completely from the command line. A new IDE called MonoDevelop is available for C# and Gtk#.
MonoDevelop is based on the Gnome IDE, so it behaves differently than Visual Studio. However, MonoDevelop makes most of the features in Visual Studio available on some level. The add-in engine, for instance, makes use of the framework's reflection capabilities. In addition to writing code, gmcs can compile code right from the GUI.
Porting some Web services might pose a problem as well, since Mono does not support Web Services Extensions (WSE). Microsoft is notorious for changing its intellectual concepts on a whim, thus forcing developers to adapt or become obsolete.
In addition to WSE, the WSE2 and WSE3 APIs are not supported, since they are meant to replace the original Web services. Currently, API developers will find no alternative in Mono.
Fortunately, Microsoft's Indigo Web services might simplify this model by eliminating the need to include IIS and non-IIS environments. The Indigo services will depend solely on the Windows Activation Service on the Longhorn server. This is the Web services technology on which Mono developers are waiting for Microsoft to settle.
Next: The Bottom Line
