Foreword

When looking at the Common Language Runtime (CLR) in historical context, it's hard not to marvel at how far the platform has advanced from the circa-1990s world of COM it replaces.

Yes, there are a number of technological advances that occurred (such as ubiquitous and extensible type information, virtualized execution, first-class support for opaque structure and behavior) as we moved from COM to the CLR. The one advance over the COM era that I am personally very excited about is the fact that the core architecture of the abstract model (Common Language Infrastructure often called the CLI) was written down and published concurrently with the shipping of the DLLs and configuration scripts necessary to make the platform real.

COM suffered immensely from the fact that the product team lacked the resources to finish the COM specification (to this day, the COM specification is only available in draft form as a collection of Word files downloadable over the Web). The fact that the CLR product team had the foresight to maintain a readable, objective, and direct document that describes the contract between the CLR and your program is a concrete feature that is at least as important as fast garbage collection or a version-aware loader.^[1] When Jim Miller asked me to write the foreword for the printed and annotated version of that document, I was flattered beyond words and immediately accepted.

^[1] That Microsoft was able to shepherd that document through ECMA and ISO without losing precision or clarity is an accomplishment in itself.

There have been (and will continue to be) countless books and primers published on writing programs that run in the CLR. However, there is no single book that is more vital to the professional developer than the one you are holding in your hands, because it describes in direct yet readable terms the basic physics of what makes your programs actually work.

I caution you not to mistake this book with an "internals" book internals books by necessity tend to focus on release-specific details that are likely to change from version to version (roughly 20 percent of my own CLR book will be rendered obsolete or inaccurate by the next release of the CLR). In contrast, the book you are holding focuses only on the semantics and structure of the contract between your code and an abstract execution engine whose implementation can and will change as often as is necessary.

I encourage you to read this book twice once now and then again after you've written CLR-based programs for six months or more. I personally find that each time I read the original CLI specification, I gain new insights into how my programs work and how I can better take advantage of the capabilities and features of the Common Language Runtime. I'm certain you will too.

Don Box
Architect, Microsoft Corporation