HomeDigital EditionSearch Dotnet Cd
ASP.NET C# Certification Exams The CLI Data Access Editorials Extending .NET Fundamentals Interoperability Interviews Migrate Mobile .NET Mono .NET Interface Object-Oriented Programming Open Source Optimization Product/Book Reviews Security Source Code UML Visual Studio .NET

The issue of this magazine that you now hold in your hands represents a landmark of truly historic proportions. Never before in the realm of .NET media has any magazine dared to focus an entire issue on the topic of non-Windows CLI implementations. For many of you, this will be your very first glimpse of technologies guaranteed to dramatically change the way in which you work. For others, the very existence of this issue should be seen as the ultimate vindication of all the long hours you have labored unsung ­ building the next generation of CLI.

If you aren't familiar with the term CLI, then let me provide a very brief introduction to the term and its history. CLI stands for Common Language Infrastructure and, in common usage, is used to refer to that portion of .NET covered by so-called "open standards." Specifically, ECMA (European Computer Manufacturers Association) documents 334 and 335 establish standards for the C# language and several aspects of the .NET runtime that can be freely implemented by any interested parties. This means that, for the first time, organizations other than Microsoft are empowered to compete with Redmond to produce implementations of the .NET runtime!

To date, there are exactly four implementations of the CLI that have drawn significant media attention. By far the most important of these is Ximian's Mono Project (www.go-mono.org). As a member of the mailing list for this project, I have seen anywhere from 50­100 e-mails per day going back and forth as legions of developers work in earnest to produce a 100% free, 100% Microsoft-compatible implementation of the CLI.

The project's founder, Miguel de Icaza, is a noted celebrity and has, of course, written an article specifically for inclusion in this issue of .NET Developer's Journal. At the time of writing, they have reached version 0.19 and have produced a completely functional C# compiler, JIT engine, and interpreter ­ as well as GNU-licensed versions of many of the .NET Framework classes and libraries.

Following in Ximian's footprints is DotGNU's Portable.NET project (www.dotgnu.org). Although nowhere near as well known as Mono, the DotGNU folks have set a religious mission for themselves to produce a 100% free "complete platform for Web services" ­ of which their CLI is just one small part. For further details, see DotGNU founder Rhys Weatherley's article in this issue.

Much to many people's astonishment, Microsoft themselves have also produced a so-called "shared source" implementation of the CLI ­ SSCLI. Shared source is different from open source in a number of ways. On one hand, shared source code cannot be used for any kind of commercial endeavor without the purchase of a license from the creator ­ in this case Microsoft ­ of the code. On the other hand, unlike GNU, people who investigate shared source code to understand the way it works are not liable to see their commercial products taken away simply for having done that research.

Not all of the legal areas surrounding alternate CLI implementations are as clear as those involving the SSCLI, though. Microsoft has made many highly confusing and contradictory statements about the patents that they hold on .NET technology. No less an authority than Steve Ballmer himself has said that Microsoft will actively defend its .NET patents against infringement.

We recently offered Microsoft an opportunity to lay the community's fears to rest once and for all at our Web Services Edge East conference in Boston this month. Despite the fact that this would have proven the ideal opportunity ­ representatives from Ximian, DotGNU, and Microsoft will all be in attendance ­ Microsoft chose not to clarify their position further. So, what are developers to take away from this attitude besides fear, uncertainty, and doubt (FUD)?

Complicating matters is that the whole of the .NET CLR is not covered by the ECMA CLI standards. Only about 25% of the total .NET Framework libraries, for example, are covered. This means that classes for:

  • Windows Forms
  • Web Forms
  • Managed Providers
...are not a part of the standard. As such, duplicating them is ­ theoretically ­ actionable!

As you read this issue, you will see that different CLI implementations have dealt with these limitations in different ways. I look forward to hearing your feedback, as always, at derek@sys-con.com.

Author Bio
Derek Ferguson is editor-in-chief of .NET Developer's Journal and author of the book Mobile .NET (Apress). He is also chief technology evangelist for Expand Beyond Corporation (www.xb.com), a worldwide leader in mobile software for enterprise management. derek@sys-con.com

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.

  E-mail: info@sys-con.com