Volume Number: 19 (2003)
Issue Number: 10
Column Tag: Programming

Casting Your .NET

An Initial Look at the .NET Platform

by Andrew Troelsen

Building raw application infrastructure by hand is a time consuming, error prone and painful process. Who among us really wants to create yet another linked list, database access framework or user interface library? Thankfully, numerous platform development kits exist today. By leveraging APIs (application programming interfaces) such as J2SE/J2EE, Cocoa, and Carbon we are able to keep focused on the programming task at hand by leveraging a set of canned functionality.

As a software professional the chances are good that you are aware of a new development platform created by Microsoft named .NET (pronounced, dot net). As well, you may have also heard of a plethora of new programming languages that target this new framework such as C# (see sharp), Visual Basic.NET, managed C++ and Pascal.NET (to name a few). However, given .NET's point of origin (Microsoft), you may have naturally assumed that .NET development is solely the activity of Windows programmers. If you did make this assumption, you might be quite surprised to learn that C# and the .NET platform are alive and well under Mac OS X, as well as other Unix-based systems.

In this new MacTech series, it is my goal to provide a guided tour of the .NET platform as seen through the eyes of a Macintosh developer. Over the articles to come, you will learn how to configure your development machine(s) with the necessary infrastructure required to build various types of .NET applications using multiple .NET distributions and .NET-aware programming languages.

To begin our journey however, we need to gain a high-level perspective of .NET itself, which is the point of this first article. Please be very aware that all of the topics examined here will be further explained and expanded upon in subsequent articles. Given this friendly disclaimer, kick back with your beverage of choice and let's get to know the .NET platform.

The .NET platform is a software development API that was officially released to the programming world circa 2001. Despite the name (which tends to conjure up visions of Web-enabled front ends), the .NET platform can be used to build traditional desktop applications, Terminal applications as well as server-side Web applications and XML Web services.

Like other frameworks, .NET provides a class library that allows developers to build various forms of applications. Not only does this base class library encapsulate various primitives such as threads, object serialization services, file IO, and interaction with various hardware devices (such as printers and handheld devices), but it also provides support for a number of services required by most real world applications (e.g. GUI toolkits, XML manipulation, network protocols and so forth).

However, unlike many other frameworks, the .NET base class libraries may be accessed using numerous programming languages. Not only can developers pick their programming language of choice when building .NET solutions, but they may also create a single .NET application using multiple languages. For example, you could make use of C# to build a desktop application which communicates with a XML Web services written using Visual Basic.NET. Even more interestingly, .NET supports cross-language inheritance, cross-language exception handling and cross-language interface implementation. Given these traits, you will do well to view .NET as a language-agnostic framework.

In addition to being a language-agnostic development platform, .NET is also platform-agnostic. This tidbit is the one aspect of .NET that tends to surprise most developers. While it is true that Microsoft Corporation has never been in the business of building software that can (easily) run of multiple operating systems, the tides have turned with the release of the .NET platform. Like J2SE, the .NET platform allows you to build software that can execute on multiple operating systems without modification. Therefore, if you build a .NET-based program on your Macintosh G5, you are able distribute and execute this application on any operating system hosting the .NET runtime.

Clearly, a language and platform neutral platform such as .NET is founded upon a number of well-defined rules and underlying technologies. Given this, our next task is to preview (the operative word being preview) some key and interrelated specifications that make it all possible: the Common Language Infrastructure, the Common Type System and the Common Language Specification.

First up, we have a specification termed the Common Language Infrastructure, or simply CLI. This particular aspect of .NET is the foundation upon which the platform and language independent nature of .NET is established. The CLI is a fairly large specification that formalizes several critical elements of the platform, including:

• An abstract runtime engine termed the Virtual Execution System (VES), which is capable of hosting .NET compliant code libraries.

• The internal structure of the .NET compliant code libraries (which go by the name assemblies) to be hosted by the VES.

• A unified type system termed the Common Type System (CTS), which describes the rules used to compose the programming types contained within .NET assemblies.

• The syntax and semantics of the low-level language used to implement the types contained within .NET assemblies, termed the Common Intermediate Language (CIL).

The VES is a hypothetical execution engine that sits on top of the actual underlying operating system (such as Mac OS X or Windows XP). The primary role of the VES is to locate, load, execute and manage .NET code libraries (a.k.a. assemblies) on your behalf. As well, the VES takes care of a number of related details such as automatic memory management (via garbage collection), language integration, ensuring type safety and verifying the correctness of the assembly's CIL code (more on CIL a bit later in this article).

One a related note, if you do have some experience using Microsoft's official .NET platform, you may have heard of another term: the Common Language Runtime (CLR). Basically, the CLR is the formal name given to a VES implementation that is specific to the Windows family of operating systems. Given that we are not all that interested in the Windows-centric implementation of the CLI's execution engine, I'll stick to the more generic term 'VES' when referring to the execution engine of .NET.

The next building block of the .NET platform, the Common Type System, or CTS, is concerned with formalizing the structure of the types contained within the code libraries themselves. Simply put, the CTS specifies all of the possible data types (e.g. Booleans, strings, integers, etc) and programming constructs (e.g., iteration constructs, virtual methods, overloaded operators, type constructors and so on) supported by the .NET runtime.

One of the most fundamental rules of the CTS is the fact that every .NET type derives from a common base class named System.Object. For your edification, Listing 1 shows the C# definition of this top-most class type:

namespace System
{
   public class Object
   {
     public Object();
       public virtual Boolean Equals(Object obj);
       public virtual Int32 GetHashCode();
       public Type GetType();
     public virtual String ToString();
     protected virtual void Finalize();
     protected Object MemberwiseClone();
  } 
} 

At this point in the game, don't worry if you cannot make heads or tails of previous code listing. The point here is that the CTS is the aspect of the CLI that describes a set of rules that constitute a well-defined .NET type, one such rule being the fact that System.Object is the cosmic super class. As you would hope, other rules of the CTS and the role of System.Object (not to mention the C# programming language) will be examined in great detail at a later time.

Understand that a particular .NET language (such as COBOL.NET) is not required to support each and every aspect formalized by the CTS. For example, although the CTS does define how unsigned data types are to be represented in CIL and processed by the runtime engine, not all .NET languages support unsigned data. Given that .NET is a language-neutral platform, it would be quite helpful to have a well-defined baseline of functionality. The Common Language Specification (CLS) is effectively a subset of the CTS, which defines a set of data types and programming constructs that all .NET languages can agree upon.

When you build .NET assemblies that only makes use of the guidelines expressed by the CLS, you can rest assured that your code library can be correctly used by any .NET language (such code is termed 'CLS compliant'). On the other hand, if you build a .NET code library that makes use of features outside the realm of the CLS (but within the confines of the CTS), you have just created an assembly that may only be completely usable from select .NET programming languages.

To solidify the concepts presented thus far, figure 1 illustrates how various .NET programming languages ultimately target the VES and CTS/CLS specifications.

Now that you have a better idea regarding the role of the CLI, let's dig into some further details of the .NET type system.

The Type System of .NET

Every programming language (and therefore every programming platform) exposes a 'type system'. This term boils down to the set of syntactically well-formed user defined types (UDTs) supported by said language (or platform). To illustrate a well-know type system, consider Java. As of Java 1.4, the type system consists of class types and interface types. Beginning with Java 1.5, the type system will be expanded to include C-style enumerations. In a similar vein, the C++ programming language supports a type system consisting of the set {class, enumeration, structure}, with interfaces being simulated via class types and a corresponding typedef or two.

.NET also defines a set of possible types, which have you have seen is officially termed the CTS. As you would expect from a modern day API, this type system is extremely well organized and completely object oriented (including support for a relatively new programming paradigm termed aspect oriented programming).

To illustrate the symmetry of the .NET type system, ponder the fact that every single UDTs provided by the .NET platform, including any custom software entities you create yourself, will fall into one of the following categories:

• Class

• Interface

• Structure

• Enumeration

• Delegate

While these type categories will be fully explained in later articles, Table 1 offers high-level definitions for each member of the .NET type system.

.NET Type         Meaning in Life

Class             Class types are heap allocated entities that may be extended and modified by 
                  derived classes.  .NET classes are very similar to Java, C++ and Objective C 
                  class types. As you know, classes form the basis of the famed 'pillars of OOP' 
                  (encapsulation, inheritance and polymorphism).
                  
Interface         An interface is a collection of abstract members grouped by a particular name.  
                  Using interfaces, developers are able to establish polymorphism between types not 
                  related by classical inheritance.
                  
Structure         Structures are lightweight, stack-allocated entities that are well suited for 
                  modeling numeric, geometric and atomic user defined types.
                  
Enumeration       Enumerations (or simply, enums) are a named collection of name/value pairs.

Delegate          By far and away, .NET delegates are the most confounding 'type of type' to contend 
                  with.  For now I will simply define .NET delegates as nothing more than a type-safe 
                  and object oriented function pointer (more details to come in later articles).

Given that .NET provides many thousands of predefined types (collectively termed the 'base class libraries' or simply BCL), you will be happy to know that like-minded types are organized into a conceptual boundary termed a namespace.

The namespace concept is not new. The Java, C++ and Smalltalk languages have used similar (but not identical) concepts to partition types for years. In a nutshell, a .NET namespace is a collection of semantically related types. For example, the System.Collections namespace contains a set of classes, interfaces, enumerations, structures and delegates that represent 'types that manage other types' (e.g. linked lists, array lists, FILO / FIFO types and so on). The System.Data namespace defines numerous types that have to do with database manipulations. Table 2 documents some (but by no means all) interesting .NET namespaces.

.NET namespace   Meaning in Life

System                      The System namespace defines various core types you will use on a 
                            day-to-day basis.  Here you will find the native .NET data types, core 
                            exceptions and numerous utility types.\
                            
System.Collections          As mentioned, this namespace defines types that can contain and manage 
                            other types (e.g. ArrayList, Stack, Queue and so on).
                            
System.Data                 The .NET platform defines numerous data-centric namespaces that allow you 
                            to interact with various relational databases. System.Data is the lowest 
                            common denominator for data access under .NET.
                            
System.Drawing              The drawing-centric namespaces allow you to render graphical data to a 
                            surface (such as window of a desktop application or a region of memory).
                            
System.IO                   Defines types to work with various input/output streams. 

System.Reflection           The reflection namespaces allow you to programmatically discover the 
                            functionality of types (as well as generate new types) at runtime.
                            
System.Runtime.Remoting     .NET defines numerous namespaces which allow you to build distributed 
                            applications. 
                            
System.Web                  The Web-centric namespaces allow you to build Web-based applications 
                            (ASP.NET) and XML Web services.
                            
System.Windows.Forms        Windows Forms provides types that allow you to build traditional desktop 
                            applications. 
                            
System.Xml                  As you would hope, the .NET platform defines numerous namespaces that 
                            facilitate the manipulation of XML data.  

Regardless of which sort of application you intend to build, you will inevitably interact with numerous .NET namespaces. However, the way you programmatically denote the namespace you wish to consume will differ based upon your .NET programming language of choice. If you are using C#, you would make use of the using keyword to specify the namespaces you wish to use. For example consider Listing 2:

// My way cool C# program.
using System;
using System.Windows.Forms;
using System.Drawing;
public class MyApp
{
    // ToDo: Add some interesting code... 
}

On the other hand, if you would rather build your application using Visual Basic.NET, you use the Imports keyword to achieve the same affect, as seen in Listing 3:

' My way cool Visual Basic.NET program.
Imports System
Imports System.Windows.Forms
Imports System.Drawing
Public Class MyApp
  ' ToDo: Add some interesting code...
End Class

In either case, once you declare the namespaces you wish to consume, you are now able to access each of the types defined within the System, System.Windows.Forms and System.Drawing namespaces.

It is worth pointing out that explicitly specifying the namespaces you wish to interact with using a language specific keyword is technically optional. To understand why this is the case, allow me to define the term fully qualified name. As you have already seen, all .NET types live within a namespace definition. Thus, if you wish to make use of the ArrayList type defined in the System.Collections namespace, you might author the following C# code (Listing 4):

using System.Collections;
public class MyClass
{
  public void SomeMethod()
  {
          // Add some data to an ArrayList.
    ArrayList arList = new ArrayList();
    arList.Add(12);
    arList.Add("Don't forget wife's birthday");
  }
}

While you will typically always prefer to explicitly list the namespaces used by a given source code file, the previous code is nothing more than a short hand notation for the following code in Listing 5 (note the lack of a C# using statement):

public class MyClass
{
  public void SomeMethod()
  {
          // Add some data to an ArrayList.
    System.Collections.ArrayList arList 
      = new System.Collections.ArrayList();
    arList.Add(12);
    arList.Add("Don't forget wife's birthday");
  }
}

As you can gather, the fully qualified name of a type is simply a term used to identify a type prefixed by its defining namespace. While making use of fully qualified names may make your code painfully well documented, hand cramps are sure to follow. Given this, most programmers prefer to list the set of namespaces used by a given file using a language specific keyword.

In terms of performance, there is absolutely no difference whatsoever between identifying a type with the fully qualified name or via a namespace reference. As you will see in just a bit, the .NET platform always refers to a type using its fully qualified name. In this light, the namespace concept is simply a typing time saver.

If you have a background in the J2SE platform, understand that the C# using and VB.NET Imports keyword do not support a Java-style * notation. If you wish to access nested namespaces, you must list out each nested namespace in turn. Thus, the following C# code is syntactically correct (Listing 6):

// Making use of three drawing related namespaces.
using System.Drawing;
using System.Drawing.Drawing2D;
using System.Drawing.Imaging;

While the following Java-like notation (Listing 7) will cause a compiler error issued by the C# compiler:

//Oops!  Remember, C# is not Java!
using System.Drawing.*; 

In addition to programming with the namespaces defined by the .NET base class libraries, you may define your own custom namespaces as well. By way of a simple example, assume you have defined two class types and one enumeration. To group these items into a namespace definition, you could write the following C# code (Listing 8):

namespace MyCustomTypes
{
  public class MyClass {...}
  public class MyOtherClass {...}
  public enum MyEnum {...}
}

The corresponding VB.NET code example is quite similar (Listing 9):

Namespace MyCustomType
  Public Class MyClass
  ...
  End Class
  Public Class MyOtherClass
  ...
  End Class
  Public Enum MyEnum
  ...
  End Enum
End Namespace

If you wish to use these types from another namespace, you would simply make use of the correct language specific keyword used to reference an external namespace. For example, in C# we would write the following (Listing 10):

using MyCustomTypes;
namespace MyNewNamespace
{
  public class MyNewClass
  {  
        // You can now make use of any of the types in 
        // the MyCustomTypes namespace
  }
}

So much for our initial high-level overview of the .NET type system. At this point in the game simply understand that the .NET type system consists of the set {class, interface, enumeration, structure, delegate} and that semantically related types are grouped together using the namespace concept. Next up, let's check out further details regarding the language agnostic nature of the .NET platform.

As mentioned, one distinguishing aspect of the .NET platform is the fact that developers may make use of any combination of programming languages to access the types of the base class libraries. Microsoft itself has created five .NET-aware programming languages: C#, J#, VB.NET, managed C++ and JScript.NET. While C# and VB.NET tend to steal most of the spotlight, there are literally dozens of languages which can be used to interact with the .NET libraries. Consider the partial list offered by Table 3 (please note that the exact URLs are subject to change in the future).

.NET Aware Programming Language              Meaning in Life  

Component Pascal                             Pascal language bindings for.NET
http://www.citi.qut.edu.au/research      
/plas/projects/index.jsp . 

Eiffel                                       Eiffel language bindings for .NET.
http://archive.eiffel.com/doc/manuals/      
technology/dotnet/eiffelsharp 

Fortran                                      Fortran language
http://www.lahey.com/lf70/lf70.htm           bindings for .NET.

Perl and Python                              Perl and Python to .NET language bindings are also 
http://aspn.activestate.com/ASPN/NET         available.
               
Scheme                                       The Scheme language is supported under the .NET 
http://rover.cs.nwu.edu/~scheme              platform as well.
               
SmallScript (a.k.a., S#)                     Yes, even Smalltalk supports binding to the 
http://www.smallscript.net                   .NET platform.

When developer's first learn about the language agnostic aspect of the .NET platform, various questions tend to surface. One such question is more practical in nature, and tends to go something like this: "If all languages targeting .NET have access to the same libraries, why do we need more than one language?" The corresponding practical answer is based on the simple fact that programmers tend to be very particular which their syntactic preferences (myself included).

Some developers love to see curly brackets and semi-colons galore (as seen in C-based languages such as Objective C, C++ and Java). Others prefer more 'human-readable' syntactic tokens as found in the BASIC family of languages. Given the philosophy of .NET, we area able to stay true to our syntactic preferences while accessing the .NET base class libraries.

Furthermore, remember the obvious fact that each programming language has its own set of strengths and weaknesses. Some languages have excellent native support for advanced mathematical processing, while others excel in the realms of financial or logical processing. Again, using .NET you can capitalize upon the unique aspects of a given language while interacting with the fabric provided by the .NET base class libraries.

Obviously, knowing how to develop with a particular .NET programming language (or two) is only part of the process. Once you have authored your .NET source code files that define your namespaces and their contained types, they are fed into the related complier to produce a binary file termed an assembly. Assemblies are platform-neutral binaries blobs that contain generic descriptions of types and their implementation that are hosted by the VES. To be more specific, a .NET assembly is a unit of deployment that is composed of the following three ingredients:

• Common Intermediate Language (CIL)

• Type metadata

• Assembly-level metadata (termed the manifest)

Again, later articles will drill into the details of .NET assemblies, CIL code and metadata. However to prime the pump, let's see a simple example which illustrates the basic composition of a .NET assembly. Assume we have the following C# source code file seen in Listing 11 (note that by convention, C# code files end in a *.cs file extension):

// MyCSharpApp.cs
using System;
namespace AllMyStuff
{
  public class MyCSharpApp
  {
    public void EchoToTerminal(string message)
    {
      Console.WriteLine("You said: {0}", 
        message);
    }
  }
}

Even if you have never seen C# code before this article, the previous code example should not raise too many eyebrows. Here we see a class type with a single method named EchoToTerminal(), which takes a string type as its only parameter. This method is implemented to take the incoming argument and print the contents to the Macintosh Terminal. Notice that the WriteLine() method of the System.Console type takes a literal string argument containing an optional (and strange) token {0}, which is dynamically replaced by the specified second argument. For the time being, simply regard this notation as a kinder, simpler version of the C printf() function.

Once this source code file has been processed by the C# compiler, we end up with an assembly, which for the sake of argument, we will name MyCSharpApp.dll. Although the file extension of a .NET assembly can technically be anything you choose, you are likely to find two common extensions in use today. If you have a .NET assembly ending in the extension *.exe, you are looking at an executable program that can be directly loaded by the VES. On the other hand, assemblies which end with a *.dll file extension are dynamic link libraries which cannot run in and of themselves. Rather, *.dll files are loaded on demand my other running applications (very similar to the *.dylib modules found under Mac OS X).

As you will see in the next article, .NET distributions ship with a tool named ildasm (the CIL disassembler) which can be used to view the underlying CIL code, type metadata and assembly manifest contained within a given .NET assembly. For our current discussion, we are only concerned with the internal representation of the EchoToTerminal() member, as seen in Listing 12:

.method public hidebysig 
 instance void EchoToTerminal
 (class System.String message) cil managed 
{
  .maxstack  8
  ldstr "You said: {0}"
  call void [mscorlib]
   System.Console::WriteLine(class System.String)
  ret
}

Without getting too bogged down into the details at this point, simply notice how the C# implementation of EchoToTerminal() has been processed by the C# compiler into terms of CIL code. As you may have already guessed, the ldstr CIL operational code loads a string for use, while call is used to invoke a type member (in this case, the WriteLine() method of System.Console) with the currently loaded arguments. Finally, the ret operational code is the CIL-savvy way to return from a method.

Now assume we have implemented the same exact class type using VB.NET as shown in Listing 13 (by convention, VB.NET source code files end with a *.vb file extension):

'MyVbNetApp.vb
Imports System
Namespace AllMyStuff
  Public Class MyVbNetClass
    Public Sub EchoToTerminal(message as String)
      Console.WriteLine("You said: {0}", message)
    End Sub
  End Class
End Namespace

Once this source code file is processed by the VB.NET compiler, we can again use ildasm to view the resulting CIL generated by the VB.NET compiler (Listing 14):

.method public hidebysig 
 instance void EchoToTerminal
 (class System.String message) cil managed 
{
  .maxstack  8
  ldstr "You said: {0}"
  ldarg.1
  call void 
  [mscorlib]System.Console::WriteLine(
  class System.String, class System.Object)
  ret
}

As you have just seen, regardless of the fact that different .NET-aware programming languages define unique keywords and programming idioms, the associated compiler transforms these tokens into a common language (CIL) which is injected into the binary assembly. While it is true that individual .NET code compilers are free to take some liberties regarding the transformation of their syntactic tokens into CIL, the fact remains that as far as the .NET runtime is concerned, CIL is the only language worth speaking and the only true language processed by the .NET runtime engine.

To wrap things up for this first article, we close with a further examination regarding the platform-agnostic nature of the .NET platform.

Having a language-agnostic .NET assembly does little good to anyone unless it can be loaded, executed and processed by a runtime engine. As noted earlier in this article, the Virtual Execution System (VES) is the entity in charge of hosting a valid .NET assembly. In addition to being a language-agnostic platform, .NET is also platform-agonistic. If you have any experience with anything related to Microsoft, this last statement is sure to resonate as a flat out lie. However, as strange as it may seem, while Microsoft was developing their official .NET distribution, a team of engineers created an alternative implementation of the CLI (termed the Shared Source CLI) that may be compiled and run on numerous operating systems (including of course, Mac OS X).

Although this article has provided a high-level examination of select elements defined by the CLI, the official documents are available in Microsoft Word format at http://msdn.microsoft.com/net/ecma/. If you would rather obtain the PDF versions of these same documents, navigate to http://www.ecma-international.org/publications/standards and locate the following two documents:

ECMA-334: The formal specification of the C# programming language.

ECMA-335: The formal specification of the .NET CLI.

Yes, it's true. The Microsoft CLI documents have been submitted to ECMA as an official standard. In fact, the CLI was developed in conjunction with a number of key industry players (such as Intel and IBM).

ECMA-334 defines the syntax and semantics of C#. While I certainly encourage you to obtain and read this document, do be aware this is a rather academic treatment of the subject. Keep it handy for a rainy evening or a sleepless night, however do know that you will come to know the details of the C# programming language over the course of the articles to come.

ECMA-335 is a very critical document for all of those interested in understanding how the .NET platform can be ported to different operating systems. As well, this information is also quite helpful for tool builders who wish to build compilers for languages that target the .NET platform or geeks like us who are interested in technology.

Given that ECMA-335 is quite lengthy, it has been subdivided into a set of partitions, which is simply a fancy and overly verbose way of saying sections. Table 4 explains the content found within these partition documents.

Partition of the ECMA-335 Document   Meaning in Life

Partition I Architecture             Describes the overall architecture of the CLI, including the 
                                     rules of the CLS, the .NET type system (CTS), and the virtual 
                                     execution system (VES).  
                                     
Partition II Metadata                Describes how .NET types (and their members) are to be 
                                     represented in terms of .NET metadata.   
                                     
Partition III CIL                    This document describes all of the gory details of the Common 
                                     Intermediate Language (CIL).    
                                     
Partition IV Library                 Gives a high level overview of the minimal and complete class 
                                     libraries that must be supported in a .NET distribution.   
                                     
Partition V Annexes                  A collection of 'odds and ends' that describe class library 
                                     design guidelines, as well as the implementation of ilasm (the 
                                     CIL assembler utility).  

Always remember that at its core, the CLI is effectively little more than a set of white papers. All of the specifications set forth in these standards documents are of little practical use until they are given life in terms of a physical code base. To date, there are many implementations of the standards defined by the CLI. Some of these CLI distributions have indeed come from Microsoft proper, which as noted, are rather Windows-centric in that they leverage certain aspects of the Win32 operating system that are simply not found on other systems.

Lucky for us, there are a number of additional CLI distributions that have no ties to Microsoft (or the Win32 APIs) beyond the fact that the original specifications have been consulted as a foundation. Two of the most popular open source distributions of the CLI go by the names Portable .NET and Mono. Table 5 describes the most well known distributions of the CLI.

.NET Platform Distributions               Meaning in Life  
The Microsoft .NET Platform               This is the commercial CLI implementation offered by 
                                          Microsoft, which is geared for use by the Windows family 
                                          of operating systems.   
                                          
The Microsoft .NET Compact Framework      A stripped down version of the official MS .NET platform 
                                          that targets handheld computer devices (such as mobile 
                                          phones and Pocket PCs).
                                          
The Microsoft Shared Source CLI (SSCLI)   While this implementation of the CLI has come from 
http://msdn.microsoft.com/net/sscli       Microsoft, thecode base is platform natural.  This 
                                          distribution is more geared towards R&D efforts and 
                                          tinkering and is not intended to be a full-fledged 
                                          development platform.
                                          
Portable .NET                             This is an open source CLI implementation that intends 
www.dotgnu.org                            to account for all of the functionality found in the 
                                          commercial Microsoft .NET platform (in addition to 
                                          Unix-specific APIs).  
                                          
Mono                                      Another open source CLI implementation that also intends 
www.go-mono-org                           to compete with the commercial Microsoft .NET platform 
                                          (also in addition to Unix-specific APIs).        

Again, given that you are reading MacTech (as opposed to Windows Developers Journal) I will not spend much time at all talking about the official Microsoft .NET distributions. Over the next several articles to come, we will come to know the SSCLI. As you will see, the SSCLI is a research-focused distribution of the CLI that is a great first step for Macintosh developers interested in checking out the .NET platform and the C# programming language.

While this particular CLI distribution does not provide an implementation of GUI based toolkits (such as Windows Forms or ASP.NET), it does provide a wealth of technical information that will build your .NET muscle. As you examine the SSCLI, you will become familiar with .NET namespaces found on any CLI distributions.

Later articles will build upon your exploration of the SSCLI by examining the Portable .NET and Mono open source projects. These CLI distributions not only provide an implementation of ADO.NET, ASP.NET and Windows Forms, but ship with compilers which target a number of .NET-aware programming languages. Unlike the SSCLI, Portable .NET and Mono are intended to be a full-blown framework for 'real-world' .NET application development.

So! Here you are at the end of this article and you have yet to compile any code and undoubtedly have a number of unresolved questions regarding the .NET universe. Fear not, this was by design. The point of this first article was to lay the conceptual groundwork for the articles to come. First you learned that the CLI defines a common file format, common execution engine and common type system that can be implemented on the Mac OS X, Unix, Linux and Windows operating systems. Next you checked out some (but not all) of the namespaces provided by .NET, followed by an investigation of the language- and platform-agnostic aspects of the framework.

So, until next month, when we install and explore the SSCLI, allow me to welcome you to the .NET platform!

Andrew Troelsen is a seasoned .NET developer who has authored numerous books on the topic, including the award winning C# and the .NET Platform. He is employed as a full-time .NET trainer and consultant for Intertech Learning (www.intertechlearning.com) and spends his idle moments at work showing off his fancy new Macintosh PowerBook G4 to his envious cohorts. You can contact Andrew at atroelsen@mac.com.