Developers evaluating Mono need to know two things: how to download Mono, and what its capabilities are. Mono can be downloaded in several different forms; I will describe when using each form makes sense. More important, I will discuss which parts of .NET Mono can support now, and which it will support in the near future.

Downloading Mono
Mono is currently at version 0.19; new versions are released as Mono progresses and people have time to pack up the release. The first public release will be labeled 1.0. There are a number of ways to get Mono. There are RPMs, nightly snapshots, MonoCharge tarballs, CVS, Red Carpet channels, and installs for Windows. The nightly snapshots and CVS contain only source code, not binaries. Because of the complex dependencies between the components of Mono, it is best to get the binaries by installing a release or an RPM, or by using the install program for Windows. If you have access to the Red Carpet channels, you can install the latest release from the Mono channel. You can then get updates from the nightly snapshots or CVS, and compile them yourself. MonoCharge tarballs contain only the binaries for the executables and DLLs.

MonoCharges serve a special purpose. All .NET compilers use the runtime classes, especially System.Reflection, to generate code. This creates a chicken-and-egg problem in that the compiler needs the class libraries before the compiler can be compiled. Of course, without the compiler, the classes cannot be generated. Presumably, Microsoft bootstrapped this, completing enough of the compiler to get the needed classes to compile, then doing enough of the classes to finish the compiler. They may also have used an IL assembler to get things started. Mono got around this problem by using the Microsoft compiler under Windows to do the early compiles of both the compiler and the class libraries.

In Mono releases, the compiler and runtime classes will always match, but during development work sometimes a change in one will break the other. When this happens, developers getting code from CVS may need to get a MonoCharge with matching binaries to get things back in sync. In addition to the compiler and class libraries, MonoCharges also have executable copies of developer tools such as the assembler and verifier tools. Putting these into the MonoCharge gives developers the latest version of the tools without requiring everyone to compile them.

The Mono Web site has instructions for downloading and installing Mono, and recently added to the Mono Project are Monkey Guides, which serve as tutorials and manuals.

Mono Tools
Some Mono developers, myself included, use Microsoft Visual Studio on Windows for developing both .NET applications that run on Mono, and Mono itself. For those who wish to develop using Linux, there are several options. For hardcore Emacs users, there is a C# module that enables all the features you would expect for C# syntax. For those who prefer an integrated development environment, there are SharpDevelop, an open-source IDE for C#; and the IBM Eclipse project, which now supports C# development. Other tools in the Mono tool chest include an IL assembler and disassembler, debugger, and, just added, a code coverage profiler.

The Mono Project
The core of the Mono Project consists of the .NET runtime, the C# compiler, and the core ECMA (European Computer Manufacturers Association) classes. These are close to complete, and the main work left is debugging and tuning. However, only the simplest of programs can run using these capabilities. The 300 classes Microsoft submitted to the ECMA standards committee comprise only about 10 percent of the classes that ship with the Microsoft developer tools. Some key namespaces not included in the ECMA standards include System.Windows.Forms (SWF), ADO.NET, ASP.NET, Microsoft.VisualBasic, System.Runtime.Interop (needed for COM/ActiveX), and System.EnterpriseServices. VB.NET itself is also missing from the standard. The long-term goal of the Mono Project is to support as much of the Microsoft .NET runtime capabilities as is feasible.

Because of their complexity and Windows centricity, some of these technologies may never be fully supported by the Mono Project. Functionality that relies on COM/ActiveX is one such area. Duplicating COM/ActiveX is far beyond the scope of the Mono Project, and although there are existing implementations of COM for Unix, none of them are widely available. This means any .NET application that uses COM/ActiveX will not run well on Mono for the foreseeable future. Although the System.EnterpriseServices namespace has been started, it also uses so many Microsoft-specific technologies that it will be difficult to complete the implementation for non-Windows systems. Mono is actively seeking other open-source projects that have solved some of these problems, such as using Winelib (Winelib is a more portable version of Wine) for SWF, and Libgda and unixODBC for ADO.NET's database support.

System.Windows.Forms
SWF is one namespace that is tightly tied to Microsoft technologies. Its large size (over 300 structures, classes, enums, interfaces, and delegates, containing over 20,000 items) and dependence on WIN32 APIs will make SWF one of the trickier parts of the Mono Project to implement. However, support for SWF seems crucial to the success of Mono as a viable alternative to Microsoft, so a lot of effort will go into trying to get it right. More than 20 programmers have contributed to SWF. As a result of that effort, all enums, interfaces, delegates, and structures (with the exception of one constructor) are complete, as are about a third of the (simplest) classes. All of the classes have been stubbed out, and most have at least some start on implementation, so the foundation for SWF is in place.

However, even with all this, verifier tools still show about 20,000 issues left with SWF. Two reasons this number is so high are that it includes numerous trivial errors, such as the naming of parameters used in functions (in this case each function would generate an error for each parameter), and errors that are inherited (in this case a single error will show up in several derived classes). Still, there is a huge amount of work left to be done before SWF is complete.

Even more difficult are the SWF dependencies on the WIN32 API and messages. Many SWF classes need to make WIN32 API calls, and all classes that display a control must implement WinProc to process Windows messages. Not only are the messages that are sent important, but also in some cases their order is just as important. On top of all this, many SWF-based programs will also use other WIN32API functions. Because of these requirements, it seems that SWF will need to use Winelib if it is to be able to run programs based on the Microsoft implementation of SWF.

There are difficulties with using Winelib. Currently we are having problems because of conflicts with the Pthreads library. Pthreads (or Posix Threads) is the Unix library that handles thread management. Because threads are different on different operating systems, and Winelib desires to be portable, the Winelib project supplies their own equivalent of Pthreads, which has added functionality to support Windows-style thread services and portability across different operating systems. Unfortunately, Winelib does not implement the entire functionality of Pthreads, which the rest of Mono depends on for its threading capability. At the time of this writing, the only way to run SWF programs outside of Windows is to disable garbage collection. This obviously must be fixed before SWF can be released, but how to fix it is unclear. Since threading issues are complex and dependent on the operating system, this is expected to be a very difficult issue to resolve. (Although, as I write this, I am receiving an unconfirmed report that a solution may not be so difficult after all.)

Programmers moving to .NET from Linux have an easier path. Gtk#, a C# binding to the GTK libraries, has been written and is complete. Work on Gtk# is now focusing on tuning and adding .NET enhancements. One .NET enhancement being worked on allows programs designed using Glade, an interface designer for GTK and GNOME, to use attributes on class fields to bind class fields with widget properties. Mono has a great tutorial for Windows programmers wanting to try out Gtk#. As Gtk# is mostly complete, there are also a number of sample programs, including some "real" programs written by people outside of the Mono Project. These are both good examples of how to use Gtk#, and a testament to the capabilities of the Mono Gtk# implementation. mPhoto, a digital photograph organizer supported by the Mono Project, and SkyNET, a program that displays the night sky (screenshots are available at http://es.geocities.com/pedroabelleira/screenshots.html), are two good examples of Gtk# programs for .NET and Mono.

Other Key Classes
Many other classes, most notably ADO.NET and ASP.NET, are progressing very well. In fact, the Mono version of ASP.NET is so good that ENT News (http://entmag.com/news/article.asp?EditorialsID=5638) reports that a survey by Netcraft showed that 1 percent of all ASP.NET servers on the Internet were running Mono!

It was surprising that Mono even showed up on the survey; the Mono version of ASP.NET had only been working for a few weeks, and the Microsoft version had been available in (at least) beta for much more than a year. It will be interesting to watch this number rise as word gets out, and Mono matures. Currently, the ASP.NET hosting classes are complete, the HTML controls are going through final bug fixes, and WebControls should be complete by the time you read this. Mono has a sample XSP server written in C# that is being used to help with final debug of the Web classes. The Mono implementation of ASP.NET can also be used as an Apache loadable module.

The Mono implementation of ADO.NET is also going well. The implementation currently has direct support for seven different databases, and the ability to connect to 23 others using Libgda and (on Unix systems) unixODBC. Some of the supported databases are: Microsoft, Oracle, MySQL, and TDS, as well as ODBC and OLE DB databases. Most SQL statements have been implemented, allowing such things as commits and rollbacks, and more. A number of tools such as a SQL command builder have also been created. Still a lot of row and table functionality needs to be implemented.

Languages Other Than C#
Mono also supports other programs and languages. Because the .NET runtime and Mono are both based on the same ECMA standards, any .NET program should run under Mono, provided all the needed classes and libraries are available.

For other languages, the first thing needed is a compiler. These can be acquired from Microsoft, other open-source projects, third parties, and the Mono Project itself. Many compilers have been written using .NET and, if they have no other dependencies, these can be used directly with Mono. In other cases a program can be compiled using Microsoft tools on Windows, and then the compiled program can be executed under Mono.

The Mono Project mainly supports C#, because it is crucial to the rest of the project (since it is all written in C#!), but within Mono there are also projects creating compilers for MonoBasic, MonoLogo, and JANET (JScript). MonoLogo is a small side project. Mono had an ECMA 3 script project, but has now merged the JANET JScript compiler project into Mono. Although this is JScript, and not Java (big difference!), it is a great addition to Mono and should be invaluable, especially to users of Mono ASP.NET.

MonoBasic, the Mono equivalent of VB.NET, can compile simple programs and is gaining momentum, but it is still at an early stage in its development. Mono can run programs compiled with the Microsoft VB.NET compiler, provided they do not use any unavailable libraries. By default, Microsoft VB.NET programs include the Microsoft.VisualBasic namespace. Many VB.NET programs do not use this library, and for these programs, the dependency can be removed. Mono is also working to duplicate the functionality of this library. Like MonoBasic, the Microsoft.VisualBasic library has minimum functionality, but after a lull, it is once again maturing rapidly. Note: C# programmers may include a reference to Micro- soft.VisualBasic.dll to gain access to functions such as Beep, the financial class, and others.

The Future
Mono is also keeping up with the future. Two new versions of .NET have been announced, 1.1, and 2.0. Version 1.1 is due for release from Microsoft in April. The main changes are in the System.Data (486), Mscorlib (149), System.EnterpriseServices (116), System (92), System.Xml (52), SWF(48), and System.Web (46) namespaces. The changes have already been added to SWF, and many of them to System.Data. I do not know the status of the other namespaces, but given the modest nature of the changes, I suspect they support v1.1 to the same extent that they support v1.0 (note that SWF and System.EnterpriseServices do not yet support v1.0 very well).

For version 2.0 the Mono Project is following the progress of the ECMA standards and Microsoft announcements and plans to stay as current as possible. As a guess, I think SWF will see significant changes in version 2.0. Changes planned for the core ECMA classes can be better foreseen due to the standardization process. The big changes that Microsoft has submitted to the ECMA committee are iterators (which make containers easier to write and use), generics (the equivalent of C++ templates for C#), and partial classes (the ability to split the implementation of a large class into more than one physical file). After the ECMA committee modifies and ratifies the specification, Microsoft is expected to implement any changes before the release of v2.0. Programmers on the Mono Project are studying these proposed changes and preparing to implement them.

Fast Moving
When I started writing this article, the Monkey Guides were only a week old, and the profiler and JANET were not even part of the project; while writing it, I received information that may get us past a major roadblock hindering SWF development. This is indicative of how fast Mono is adding functionality. By the time you read this, Mono will have improved even more. Come look at our home page (www.go-mono.com) and check the news to see what is happening. Maybe even contribute some code while you are there!

Author Bio
Dennis Hayes is a senior software engineer at Raytek Corporation in Santa Cruz, CA, where he writes process-control software. Dennis has been involved with the Mono Project for over a year, and is in charge of the System.Windows.Forms and System.Drawing namespaces. dennish@raytek.com