Review: Move .Net Apps To Linux
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 To run ASP.Net code, Mono developers provide two options: run code with Apache or use an XSP server.
However, the developers recommend using XSP only for development and not production. The XSP server is useful when debugging code through the command line. With Apache, ASP.Net code does not need a lot of configuration. This is great news for Windows developers, since Apache requires adjusting many configurations.
Mono's mod_mono.so module for Apache is simple to use. The mod_mono server has a Web-based control panel and supports Unix TCP sockets, including multiple path configurations. In addition to Novell's SUSE, the mod_mono server can work with Ubuntu. Configuring mod_mono on Ubuntu's Apache takes a little manual work. The Mono project has made it possible for developers to create alternatives to the Microsoft toolset. For instance, developers can choose from a number of tools that either replace various capabilities of ASP.Net or work on top of ASP.Net.
The Castle project is one of the most exciting subprojects spun out of Mono. Castle was inspired by the Ruby on Rails framework, so it supports the MVC architecture.
Developers have ported Java frameworks and tools into the Mono runtime. For instance, developers can use the Spring.Net framework to build applications on the Spring Framework J2EE project. Developers can mix and match Mono-based ASP.Net and ADO.Net with Spring services and other application interfaces. Developers can even use front-end code using Ajax generators and runtimes to remove the ASP.Net HTML model.
Mono's ADO.Net supports many open-source and commercial databases. Here, too, developers ported some Java libraries and tools.
The NHibernate tool, for example, stems from the Java Hibernate project. NHibernate is a powerful extension of the SQL language that allows developers to build persistent classes that map to database objects. Developers also can choose from many open-source data providers and tools such as MonoQuery.
Through Novell's Developer Service, Mono users can purchase support for $2,500 for a year. Support can range from five incidents to having a dedicated engineer.
The future of the Mono project looks bright. While Mono developers are paving the way for Microsoft developers to port code to Linux, most Microsoft developers are still entrenched in the Microsoft sphere and for good reason: Mono is still slower, and many projects are incomplete.
Engineers hope to see projects like DotNetNuke and others on Sourceforge migrate to Mono in the near future so that Microsoft developers can take advantage of Linux.