What Happened?
In 1998, Microsoft held a Professional Developer's Conference
(PDC) in San Diego. COM luminary Charlie Kindel stood up in a
general session and proclaimed "no more GUIDs-no more HRESULTs-no
more IUnknown." He and Mary Kirtland proceeded to show the basic
architecture of the CLR, then known as the COM+ Runtime. Later in
the session, Nat Brown and David Stutz stood up and demonstrated
crosslanguage inheritance using Visual Basic and Java. Attendees
actually went home with CDs containing primitive versions of
compilers that could reproduce this very odd demonstration. It is
now February 2002, and this technology has finally shipped in
release form.
There are two days that will forever demarcate the evolution of
the Microsoft platform. On July 27, 1993, Windows NT 3.1 was
released, marking the end of the DOS era. On February 13, 2002, the
Common Language Runtime (CLR) was released as part of the .NET
Framework, marking the end of the COM era.
The .NET Framework is a platform for software integration.
Fundamentally, the .NET Framework provides two core integration
technologies. The Common Language Runtime (CLR) is used to
integrate software within a single operating system process. XML
Web Services are used to integrate software at Internet scale. Both
rely on similar ideas, that is, strongly typed contracts and
encapsulation. Fundamentally, though, they are two distinct
technologies that one can elect to adopt independently of one
another. It is completely reasonable to adopt XMLWeb Services prior
to the CLR (in fact, many production Web services have already done
this). It is also reasonable to adopt the CLR in the absence of
XMLWeb Services in order to access CLRspecific features such as
code access security or superior memory management facilities.
Going forward, however, both the CLR and XML Web Services will be
central to the Microsoft development platform, and it is only a
matter of time before both of these technologies play a role in
everyone's development experience.
The CLR and XML Web Services are both focused on strongly typed
contracts between components. Both technologies require developers
to describe component interactions in terms of type definitions or
contracts. In both technologies, these contracts share two key
ideas that tend to permeate their use: metadata and
virtualization.
Both the CLR and XMLWeb Services rely on highfidelity,
ubiquitous, and extensible metadata to convey programmer intention.
Metadata conveys the basic structure and type relationships to the
developers who will consume a CLR component or XMLWeb Service.
Equally important, ubiquitous metadata informs the tools and
underlying platform of what the component developers had in mind
when they were authoring the code.
This metadatadirected "clairvoyance" allows the platform to
provide richer support than would be possible if the component were
completely opaque. For example, various aspects of objecttoXML
mapping are captured in metadata for use by the CLR's XML
serializer. How the developer intended the XML to look is conveyed
through declarative metadata extensions rather than through
explicit laborintensive coding.
The second key idea that permeates CLR and XML Web Service
contracts is the notion of virtualization. Both technologies
emphasize the separation of semantic intentions from physical
implementation details. Specifically, the metadata for both
technologies work at an abstract structural level rather than in
terms of lowlevel data representations and implementation
techniques. When developers specify intercomponent contracts at
this "virtual" level, the underlying platform is free to express
the contracts in the most appropriate manner available. For
example, by expressing Web Service contracts in terms of an
abstract data model, the plumbing is free to use an efficient
binary data representation for performance or to use the textbased
XML 1.0 representation for maximum interoperability.
Because contracts are virtualized, this specific detail of the
contract can be bound at runtime based on postdevelopment
characteristics.
Because this volume focuses exclusively on the CLR, a working
definition of the CLR is in order. The CLR is fundamentally a
loader that brings your components to life inside an operating
system process. The CLR replaces COM's
CoCreateInstance and Win32's LoadLibrary
as the primary loader for code.
The CLR loader provides a number of services beyond what COM and
Win32 offered before it. The CLR loader is versionaware and
provides flexible configuration of version policies and code
repositories. The CLR loader is securityaware and is a critical
part of the enforcement of security policy. The CLR loader is
typeaware and provides a rich runtime environment for the explicit
management and creation of types independent of programming
language. In short, the CLR loader is an advanced component
technology that supplants COM as Microsoft's primary inmemory
integration strategy.
The CLR is made accessible through compilers that emit the CLR's
new file format. Program language wonks view the CLR as providing
key building blocks for compiler writers, building blocks that
reduce the complexity of compiler implementations. In contrast,
systems wonks often view programming languages as facades or
"skins" over the underlying constructs of the CLR. The author falls
firmly into the latter camp. However, programming languages are a
necessary lens through which even lowlevel systems plumbers view
the CLR. To that end, examples in this book are written in various
programming languages because binary dumps of metadata and code are
arcane to the point of being incomprehensible.
About This Book
I try very hard to make a book readable and accessible to a wide
array of readers, but invariably, my terse writing style tends to
make a "Don Box book" a challenge to get through. Experience has
shown me that I am horrible at writing tutorials or primers. What I
can do reasonably well is convey how I see the world in book form.
To that end, it is not uncommon to need to read a Don Box book more
than once to get the intended benefits.
As the previous paragraph implied, this book is by no means a
tutorial. If you try to learn .NET Framework programming from a
standing start using this book, the results may not be pretty. For
readers looking for a good tutorial on .NET programming techniques
or the C# language, please read Stan Lippman's C# Primer
(AddisonWesley, 2002) or Jeffery Richter's Applied .NET
Framework Programming (Microsoft Press, 2002) before taking on
this book.
This book is divided into two volumes. Volume 1 focuses on the
Common Language Runtime. Volume 2 will focus ST3on XMLWeb Services.
Although the two technologies share a fair number of core concepts,
the thought of covering them both in a single book made my head
spin.
This book was written against Version 1 of the CLR. Some of the
internal techniques used by the CLR may evolve over time and may in
fact change radically. In particular, the details of virtual method
dispatch are very subject to change. They are included in this book
largely as an homage to COM developers wondering where the vptr
went. That stated, the basic concepts that are the focus of this
book are likely to remain stable for years to come.
Throughout the book, I use assertions in code to reinforce the
expected state of a program. In the CLR, assertions are performed
using System. Diagnostics.Debug.Assert,
which accepts a Boolean expression as its argument. If the
expression evaluates to false, then the assertion has failed and
the program will halt with a distinguished error message. For
readability, all code in this book uses the short form,
Debug.Assert, which assumes that the
System.Diagnostics namespace prefix has been
imported.
My perspective on .NET is fairly agnostic with respect to
language. In my daily life, I use C# for about 50 percent of my
CLRbased programming. I use C++ for about 40 percent, and I resort
to ILASM for the remaining 10 percent. That stated, most
programming examples in this book use C# if for no other reason
than it is often the most concise syntax for representing a
particular concept or technique. Although some chapters may seem
languagefocused, none of them really is. The vast majority of this
book could have used C++, but, given the tremendous popularity of
C#, I elected to use C# to make this book as accessible as
possible.
This book focuses on the Common Language Runtime and is divided
into 10 chapters:
- Chapter 1-The CLR as a Better COM: This chapter frames the
discussion of the CLR as a replacement for the Component Object
Model (COM) by looking at the issues that faced COM developers and
explaining how the CLR addresses those issues through
virtualization and ubiquitous, extensible metadata.
- Sum Chapter 2-Components: Ultimately, the CLR is a replacement
for the OS and COM loaders. This chapter looks at how code is
packaged and how code is loaded, both of which are done
significantly differently than in the Win32 and COM worlds.
- Chapter 3-Type Basics: Components are containers for the code
and metadata that make up type definitions. This chapter focuses on
the CLR's common type system (CTS), including what constitutes a
type and how types relate. This is the first chapter that contains
significant chunks of source code.
- Chapter 4-Programming with Type: The CLR makes type a
firstclass concept in the programming model. This chapter is
dedicated to the explicit use of type in CLR programs, with an
emphasis on the role of metadata and runtime type information.
- Chapter 5-Instances: The CLR programming model is based on
types, objects, and values. Chapter 4 focused on type; this chapter
focuses on objects and values. Specifically, this chapter outlines
the difference between these two instancing models, including how
values and objects differ with respect to memory management.
- Chapter 6-Methods: All component interaction occurs through
method invocation. The CLR provides a broad spectrum of techniques
for making method invocation an explicit act. This chapter looks at
those techniques, starting with method initialization through JIT
compilation and ending with method termination via strongly typed
exceptions.
- Chapter 7-Advanced Methods: The CLR provides a rich
architecture for intercepting method calls. This chapter dissects
the CLR's interception facilities and its support for
aspectoriented programming. These facilities are one of the more
innovative aspects of the CLR.
- Chapter 8-Domains: The CLR uses AppDomains rather than OS
processes to scope the execution of code. To that end, this chapter
looks at the role of AppDomains both as a replacement for the
underlying OS's process model as well as an AppDomain's
interactions between the assembly resolver or loader. Readers with
Java roots will find the closest analog to a Java class loader
here.
- Chapter 9-Security: One of the primary benefits of the CLR is
that it provides a secure execution environment. This chapter looks
at how the CLR loader supports the granting of privileges to code
and how those privileges are enforced.
- Chapter 10-CLR Externals: The first nine chapters of this book
are focused on what it means to write programs to the CLR's
programming model. This concluding chapter looks at how one steps
outside of that programming model to deal with the world outside of
the CLR.
0201734117P09272002