Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

An Introduction to Mono Development

Microsoft's .NET Framework CLI implementation isn't the only CLI development game in town. The Mono project is both surprisingly mature, and surprisingly compatible—and you can deliver applications built on it to multiple platforms, including Windows.


advertisement
any .NET developers, accustomed to Microsoft's Windows-only development tools' capabilities, are quite surprised when they learn that .NET is platform-independent. But it's true. You can compile and execute .NET assemblies on operating systems other than Microsoft Windows. Currently, Mac OS X, Solaris, AIX, and numerous flavors of Unix/Linux can be happy homes for your .NET binaries. Even after developers are made aware of .NET code's cross-platform capabilities, they often assume that the scope of platform-independent .NET development is limited to little more than "Hello World" console applications. Here's the reality. Today, you can build production-ready assemblies that make use of ADO.NET, Windows Forms (in addition to alternative GUI toolkits such as Gtk#), ASP.NET, and XML Web services.

This article introduces Mono, an open source and OS-agnostic implementation of .NET. You should understand right up front that you can compile the sample application developed in this article on any Mono-supported platform, including (surprise, surprise) Microsoft Windows. Here's some background information on how Mono can make that happen. The Role of the Common Language Infrastructure (CLI)
When C# and the .NET platform were released to the world at large, Microsoft Corporation submitted two formal specifications to ECMA (European Computer Manufacturers Association). Once approved, these same specifications were submitted to the International Standards Organization (ISO) and ratified shortly thereafter.

So, why on earth should you care? Simply put, these two specifications provide a roadmap for other companies, developers, and organizations to build their own custom distributions of the C# programming language and the .NET platform. The two specifications in question are:

  • ECMA-334, which defines the syntax and semantics of the C# programming language.
  • ECMA-335, which defines numerous details of the .NET platform, collectively termed the Common Language Infrastructure (CLI).
ECMA-334 tackles the lexical grammar of C# in an extremely rigorous and scientific manner (as you might guess, this level of detail is quite important to those implementing their own C# compiler). However, ECMA-335 is the meatier of the two specifications, so much so that it has been broken down into five partitions (see Table 1).


Table 1The ECMA-335 specification is partitioned into several topics.

ECMA-335 Partition Meaning in Life
Partition I: Architecture Describes the overall architecture of the CLI, including the rules of the Common Type System, Common Language Specification, and the mechanics of the .NET runtime engine.
Partition II: Metadata Describes the details of the .NET metadata format.
Partition III: CIL Describes the syntax and semantics of the common intermediate language (CIL) programming language.
Partition IV: Libraries Gives a high level overview of the minimal and complete class libraries which a CLI-compatible .NET distribution must support.
Partition V: Annexes A collection of "odds and ends," examining topics such as class library design guidelines and the implementation details of a CIL compiler.

The point of this article is not to dive into the details of the ECMA-334 and ECMA-335 specifications—nor are you required to know the ins-and-outs of these documents to understand how to build platform-independent .NET assemblies. If you are interested however, you can download both of these specifications for free.


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap