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.
|
Namespace |
Percent Complete |
|
System.Web |
98% |
|
System.Web.Services |
97% |
|
System.Data |
90% |
|
System.XML |
99% |
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.
