Essential .NET: The Common Language Runtime

• Authors: Don Box;Ted Pattison
• Venue: Essential .NET: The Common Language Runtime
• Year: 2002

From the Book: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 cross-language 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. In May of 1993, Windows NT 3.1 was released, which marked 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 XML Web 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 CLR-specific 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 XML Web Services rely on high-fidelity, ubiquitous, and extensible metadata to convey programmer intention. Metadata conveys the basic structure and type relationships to developers who will consume a CLR component or XML Web Service. Equally important, ubiquitous metadata informs the tools and underlying platform of what the component developer had in mind when they were authoring the code.This metadata-directed "clarvoyance" allows the platform to provide richer support than would be possible if the component was completely opaque. For example, various aspects of object-to-XML 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 labor-intensive 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 low-level data representations and implementation techniques. By specifying inter-component contracts at this "virtual" level, the underlying platform is free to express the contracts in the most appropriate manner available. For example, by expressingWeb Service contracts in terms of an abstract data model, the plumbing is free to use an efficient binary data representation for performance or the text-based XML 1.0 representation for maximum interoperability.Because contracts are virtualized, this specific detail of the contract can be bound at runtime based on post-development 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 before it offered. The CLR loader is version-aware and provides flexible configuration of version policies and code repositories. The CLR loader is security-aware and is a critical part of the enforcement of security policy. The CLR loader is type-aware and provides a rich runtime enviroment 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 in-memory 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 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 neccessary lens through which even low-level systems plumbers view the CLR. To that end, examples in this book are written in various programming languages, since binary dumps of metadata and code are arcane to the point of being incomprehensible.About this bookThis book is divided into two volumes. Volume 1 focuses on the Common Language Runtime. Volume 2 will focus on XML Web Services. While 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 looking for 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% of my CLR-based programming. I use C++ for about 40%, and resort to ILASM for the remaining 10%. That stated, most programming examples use C# if for no other reason than it is often the most concise syntax for representing a particular concept or technique. Though some chapters may seem language focused, none of them really are. 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 ten 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 how the CLR addresses those issues through virtualization and ubiquitous, extensible metadata.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 significantly different from 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 first-class 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. The previous chapter 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 aspect-oriented 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/loader. Readers with Java roots will find the closest analogue 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 granting 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.