As the title of this article suggests, you are probably asking yourself “How can ASP.NET applications run on Linux?”  The answer comes in the form of a free software download from Ximian, a little known company that was recently acquired by networking giant Novell.  The Mono Project, as the software development effort is officially known, is primarily designed to allow Unix and Linux developers to compile and run .NET applications on their platform of choice.  However, if you’re not a Unix or Linux developer don’t turn the channel just yet! The odds are good that at least deploying ASP.NET applications on Linux may still be in your future because of the reduced costs associated with this combination.  Even if you have no personal interest in Linux or Mono’s cross-platform goals it’s still a good idea to be prepared to offer this low-cost option to your customers or management.

As you may be aware, most companies offering low-cost web hosting services provide their customers with access to a Linux box running Apache.  They also generally provide access to some form of open source database software (often MySQL or PostgreSQL) as well as access to a scripting language like PHP that is pretty much equivalent to classic ASP. While this combination can be employed effectively to build a variety of web-based applications, it’s impossible to deny that there are many benefits to using a more modern language architecture like ASP.NET.  Customers who want the best of both worlds—that is, the ability to deploy ASP.NET applications in a low-cost environment—will inevitably be drawn to the powerful combination of Linux and Mono to provide this capability.

As we get into the nitty-gritty of our discussion of Mono’s compatibility with .NET be prepared for some good news and some not so good news.  As tradition dictates, we’ll look at the good news first.

Our first bit of good news is that if you want to use Mono to test your applications for compatibility but have little interest in establishing a Linux test environment then you’re in luck.  Mono provides a simple Windows executable that will install and configure your system for Mono development.  In fact, it’s important to note that Mono has no dependencies on .NET applications or class libraries so you don’t need to have .NET installed on Windows to develop .NET applications with Mono.  To download the latest Mono installer head on over to http://www.go-mono.com/download.html and grab the latest version. 

Mono currently supports ASP.NET deployment on Linux using either a small, light-weight web-server written in C# called XSP or via an add-on for Apache called mod_mono.  Whereas XSP is ideal for experimentation and development scenarios mod_mono is clearly the choice for deployments demanding greater performance and reliability.  Currently, Mono’s XSP web-server is not included as part of the Mono distribution.  Although downloading the C# source code for XSP is easy enough, actually building the source on Windows is a pain since Mono’s build system is very UNIX-centric in its reliance on “make” files.  Since most Windows users don’t have the tools required to compile “make” files I’ve posted the XSP executable at my web-site here.  What’s interesting to note is that although I built the XSP executable on Linux it runs just fine under Windows, which brings us to our next bit of good news…

Because Mono’s .NET compatible run-time (officially called the CLI, short for Common Language Infrastructure) is byte code compatible with Microsoft .NET binaries, you can (at least in theory) copy an existing .NET application from Windows to Linux and run it without recompilation.  Likewise, any application compiled using Mono’s C# compiler will also run without recompilation under Windows.  Of course, the truth of the matter is that, in either case, if you write your application using assemblies that are not available on the alternative platform you’re going to run into problems and therein lies the rub…

Of the various .NET namespaces that often crop up during ASP.NET development most are very well supported considering Mono has not yet reached the 1.0 milestone.  The chart below (Figure 1) will give you a good idea of where Mono’s porting efforts currently stand in regard to several namespaces typically associated with ASP.NET development. If you want to keep tabs on the development of any particular namespace you should head over to Mono’s web-site and check out their Class Status Page at http://www.go-mono.com/class-status.html. For a broad view of Mono’s release schedule take a look at their roadmap page at http://www.go-mono.com/mono-roadmap.html.

As the table above indicates, the ADO.NET namespace is about 90% complete. Moreover, Mono provides reasonably functional SQL Server drivers and work to improve them continues at a pretty fast clip. The biggest problem Windows developers are likely to face, however, is that any hosting company unwilling to spring for a Windows server license is not likely to provide you with access to Microsoft SQL Server either.  Instead, you will most likely be given access to either MySQL or PostgreSQL. The former, MySQL, is generally more popular in the Linux world because of its simplicity and reputation for fast SELECT queries which makes it ideal for serving dynamic web content.  PostgreSQL is no slouch either and has features which make it a much better match with SQL server from the standpoint of the developer but, alas, at the cost of additional complexity.

Now for that bit of bad news I mentioned.  Although Mono’s implementation of ASP.NET is fairly complete, one functional area closely related to ASP.NET is not very far along in development; namely, the System.EnterpriseServices namespace.  The EnterpriseServices namespace essentially wraps underlying Windows operating system services to provide support within .NET for transactions, message queuing, and other enterprise services.  The problem is that to implement these same services Mono will have to provide either native .NET implementations or wrap similar services that are available on the Linux platform.  In either case, compatibility will likely be an issue so you’ll probably want to avoid this namespace for some time to come. 

Since Mono is by definition attempting to reverse engineer and re-implement Microsoft’s released implementation and specifications it stands to reason that they will always be one step behind the latest Microsoft release.  In addition, given the differences between the Windows and Linux platforms it is quite likely that Mono will offer additional APIs to offer full coverage on their platform of choice.

Now that you understand that Mono’s implementation of .NET is still a work-in-progress it’s important to reflect on how much has been accomplished by the talented programmers contributing to this effort.  A good example of the progress Mono has made toward providing a viable cross platform ASP.NET implementation is found in the fact that a number of Microsoft’s sample applications including IBuySpy work unmodified on Mono. As for performance, although Microsoft’s C# compiler generates more performant code is currently more performant than that produced by mono’s C# compiler the gap is closing rapidly. In addition, Mono’s support for Visual Basic.NET is shaping up quite nicely.

Even though Mono has yet to reach a 1.0 release at least one hosting provider, http://www.monohosting.net/, has committed to providing low-cost ASP.NET hosting using Mono.  In the meantime, you can experiment with this interesting technology and even contribute to the project yourself if you are so inclined.  For more information on how you can help Mono develop into the powerful cross-platform development tool it may well become just click on this link:  http://www.go-mono.com/contributing.html

By submitting a large chunk of .NET’s technology architecture to ECMA, an international standards body, Microsoft clearly opened the door for compatible implementations to be devised. Unfortunately, the documents submitted by Microsoft failed to include many of the API’s provided by Microsoft with the .NET SDK.  As a result, in addition to the ECMA specifications, Mono also uses Microsoft’s published APIs as a guide to developing those namespaces that were not submitted to ECMA for standardization.

Regarding the issue of software patents, rather trying to explain Mono’s position on this issue I’ve included the relevant FAQ response from their web-site below:

Thus ends the first part of our coverage of Mono’s implementation of ASP.NET on both Linux and Windows.  Hopefully this article has helped you to understand what Mono is attempting to achieve, has brought you up to date on the project’s progress, and has made you aware of the challenges the project faces going forward.   

Next time we’ll get into some of the nitty-gritty details of running Mono on Windows and build a simple ASP.NET application using Mono’s command-line tools.  See you then!