Pro CSharp 2008 And The .NET 3.5 Platform [eng]

So, at this point you have seen the process of building .NET applications that talk to COM types and COM applications that talk to .NET types. Again, while there are many additional topics regarding the role of interop services, you should be in a solid position for further exploration.

Summary

.NET is a wonderful thing. Nevertheless, managed and unmanaged code must learn to work together for some time to come. Given this fact, the .NET platform provides various techniques that allow you to blend the best of both worlds.

A major section of this appendix focused on the details of .NET types using legacy COM components. As you have seen, the process begins by generating an assembly proxy for your COM types. The RCW forwards calls to the underlying COM binary and takes care of the details of mapping COM types to their .NET equivalents.

The appendix concluded by examining how COM types can call on the services of newer .NET types. As you have seen, this requires that the creatable types in the .NET assembly are registered for use by COM, and that the .NET types are described via a COM type library.

1316 APPENDIX B ■ PLATFORM-INDEPENDENT .NET DEVELOPMENT WITH MONO

“Hello World” console applications. In reality, however, you can build production-ready assemblies that make use of ADO.NET, Windows Forms (in addition to alternative GUI toolkits such as GTK# and Cocoa#), ASP.NET, and XML web services using many of the core namespaces and language features you have seen used throughout this text.

The way in which .NET’s cross-platform nature is achieved is different from the approach taking by Sun Microsystems with the handling of the Java programming platform. Unlike Java, Microsoft itself does not provide installers of .NET for Mac, Linux, etc. Rather, Microsoft has released a set of formalized specifications that other entities can use as a road map for building

.NET distributions for their platform(s) of choice. Collectively, these specifications are termed the CLI.

The Role of the CLI

As briefly mentioned in Chapter 1, 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 Organization for Standardization (ISO) and ratified shortly thereafter.

So, why on earth should you care? Again, these two specifications provide a road map for other companies, developers, universities, and other such 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

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 six partitions, as listed in Table B-1.

Table B-1. ECMA-335 Specification Partitions

1318 APPENDIX B ■ PLATFORM-INDEPENDENT .NET DEVELOPMENT WITH MONO

The Scope of Mono

Given that Mono is an API built on existing ECMA specifications that originated from Microsoft Corporation, you would be correct in assuming that Mono is playing a constant game of catch up as newer versions of Microsoft’s .NET platform are released. At the time of this writing, Mono is compatible with C# 2.0/.NET 2.0. Therefore, you are able to build ASP.NET websites, Windows Forms applications, database-centric applications using ADO.NET, and (of course) simple console applications.

Currently, Mono is not completely compatible with C# 2008 or .NET 3.0/3.5. What that means is your Mono applications are currently unable (again, at the time of this writing) to make use of the following APIs:

•Windows Presentation Foundation (WPF)

•Windows Communication Foundation (WCF)

•Windows Workflow Foundation (WF)

•The LINQ APIs

•C# 2008–specific language features

Rest assured that the Novell-based Mono team is already working on incorporating these APIs and C# 2008 programming features into the Mono project. In fact, many C# 2008 language features are already part of the latest build of Mono (1.2.5), including implicit typing, object initialization syntax, and anonymous types.

■Note The C# 2008 support is enabled by passing the -langversion:linq option to the Mono C# compiler.

In addition, the Olive project, which plans to bring WPF, WCF, and WF into the Mono platform, is currently underway. LINQ support, you will be happy to know, is also moving along nicely.

■Note The Mono website maintains a page that describes the overall road map of Mono’s functionality and plans for future releases (http://www.mono-project.com/plans).

The final point of interest regarding the Mono feature set is that much like Microsoft’s .NET Framework 3.5 SDK, the Mono SDK supports a number of .NET programming languages. While this appendix will stay focused on C#, Mono does provide support for a Visual Basic .NET–compatible compiler, as well as support for many other .NET-aware programming languages.

Obtaining and Installing Mono

With this basic primer behind us, we can turn our attention to obtaining and installing Mono on your operating system of choice. Navigate to the Mono website (http://www.mono-project.com) and click the Download Now button to navigate to the downloads page. Here you are able to download a variety of installers.

I am assuming that you are installing the Windows distribution of Mono (note that installing Mono will not interfere whatsoever with any existing installation of Microsoft .NET or Visual Studio IDEs). Begin by downloading the current stable Mono installation package for Microsoft Windows and saving the setup program to your local hard drive.

■Note If you are installing Mono on a Linux-based OS, I’d suggest doing so using the Linux Installer for x86 package, which will allow you to install Mono using a friendly setup wizard (rather than forcing you to install Mono from source; be sure to read the supplied installation notes on the Mono website). If you make use of the Mac OS X Mono installer, the installation process will be identical to installing other Mac-based software.

When you run the setup program, you will be given a chance to install a variety of Mono development tools beyond the expected base class libraries and the C# programming tools. Specifically, the installer will ask you whether you wish to include GTK# (an open source .NET GUI API based on the Linux-centric GTK toolkit) and XSP (a stand-alone web server, similar to Microsoft’s webdev. webserver.exe). In this appendix, I will assume you have opted for a full installation, so be sure you have checked each option in the setup script (see Figure B-1).

Figure B-1. Select all options for your Mono installation.

All of the remaining options of the Mono installer can be left using the suggested default values.

Examining Mono’s Directory Structure

By default, Mono installs under C:\Program Files\Mono-<version> (at the time of this writing, the latest and greatest version of Mono is 1.2.5). Beneath that root you will find a number of subdirectories (see Figure B-2).

For this appendix, you need only concern yourself with the following subdirectories:

•bin: Contains a majority of the Mono development tools including the C# command-line compilers

•lib\mono\gac: The location of Mono’s global assembly cache

The Mono Development Tools

Similar to the Microsoft’s CLR distribution, Mono ships with a number of managed compilers:

•mcs/gmcs: The C# compilers

•vbnc: The Mono Visual Basic compiler

•booc: The Boo language compiler

•ilasm/ilasm2: The Mono CIL compilers

While this appendix focuses only on the C# compilers, again recall that the Mono project does ship with a Visual Basic .NET compiler. While this tool is currently under development, the intended goal is to bring the world of human-readable keywords (Inherits, MustOverride, Implements, etc.) to the world of Unix/Linux and Mac OS X (see http://www.mono-project.com/Visual_Basic for more detail).

Boo is an object-oriented statically typed programming language for the CLI that sports a Python-based syntax. Check out http://boo.codehaus.org for more details on the Boo programming language. Finally, as you might have guessed, ilasm/ilasm2 are the Mono CIL compilers (the second of which supports .NET 2.0 programming constructs).

Working with the C# Compilers

The first C# compiler for the Mono project was mcs, and it’s fully compatible with C# 1.1 (in fact, mcs is written in C#). Like the Microsoft C# command-line compiler (csc.exe), mcs supports response files, a /target: flag (to define the assembly type), an /out: flag (to define the name of the compiled assembly), and a /reference: flag (to update the manifest of the current assembly with external dependencies). You can view all the options of mcs using the following command:

mcs -?

The “generic mono C# compiler,” or gmcs, as the name implies, is a version of mcs that has support for .NET 2.0–specific C# language features (generics, covariance/contravariance, nullable types, partial types, anonymous methods, etc.) and references the .NET 2.0–based base class libraries. The command-line options of gmcs are identical to mcs, which you can verify with the following command:

gmcs -?

Given the presence of two C# compilers, you might naturally assume that only gmcs can be used to build .NET applications that make use of the C# 2.0 language enhancements. In reality, mcs was the first of the two compilers to support 2.0 features, which were perfected and ported to gmcs. The code examples in this appendix can be compiled using either of the two C# compilers, so pick your poison.

Microsoft-Compatible Mono Development Tools

In addition to various managed compilers, Mono ships with various development tools that are functionally equivalent to tools found in the Microsoft .NET SDK (some of which are identically named). Table B-3 enumerates the mappings between some of the commonly used Mono/Microsoft .NET utilities.