Foreword

In October 1999, someone I knew at Microsoft asked me if I would do some consulting work on the Microsoft .NET Framework team. At that time, I knew very little about the .NET Framework, but what I did know impressed me quite a bit, and I immediately joined the team.

At that time, the .NET Framework was internally called COM+ 2.0. But Microsoft knew that this new way of programming deserved a better name than that. Before its first release, the .NET Framework had many other names. One code name was "Lightning." This name was chosen because earlier versions of Microsoft Visual Basic had the code name "Thunder," and "Thunder & Lightning" sounded cool. (By the way, Microsoft's reference implementation of the Shared Source CLI [http://MSDN.Microsoft.com/net/sscli] is code-named "Rotor" because it is another meteorological term.) The .NET Framework was also called "NGWS" at one time, which stands for Next Generation Windows Services or Next Generation Web Services, depending on whom you ask.

Another code name for the .NET Framework was "URT," which stands for Universal Runtime. In my mind, this code name was particularly telling and indicated that Microsoft's goal was to make the CLR universally available. In other words, for Microsoft, the CLR would be the programming model for all its applications and servers. Any application that offered any kind of programmability would offer that programmability through the CLR. The full fruition of this vision is many years away, but today managed code can be written to extend the capabilities of Microsoft SQL Server, Microsoft Excel, Word, and Outlook.

However, the CLR wouldn't truly be universal unless other companies could also incorporate it into their products, enabling end users to extend these applications using managed code as well. Today, many companies do incorporate the CLR into their applications. Like SQL Server, IBM's DB2 database incorporates the CLR, enabling developers to write stored procedures in managed code. Also, AutoDesk allows users to extend its AutoCAD products by using managed code.

By incorporating the CLR into your own applications and servers, you will gain many benefits. Here's a list of just a few:

• Users can extend your application using any .NET programming language.

• Microsoft (and other companies) provides editors, wizards, debuggers, profilers, and other tools to aid your users.

• The managed objects are garbage collected so that there are no memory leaks or corruption.

• The code is verified to ensure that only safe operations are performed.

• Code can run in a secure AppDomain so that the hosting application can limit what the user's code can do.

• XCopy deployment means that it is easy to deploy, back up, restore, move, and uninstall managed assemblies.

• Users have access to all the types in the Microsoft .NET Framework Class Library as well as types created by other companies to help them in building their code.

As I said, these are just some of the benefits of incorporating the CLR into your applications and servers. The perfect resource to learn about more of these features and, more important, how to incorporate them and use them effectively is the very book you are holding in your hand!

I met Steve Pratschner in 1999 when I started consulting on the COM+ 2.0/Lightning/NGWS/URT/.NET Framework team. At the time, Steve was a program manager responsible for the CLR's loader and assembly versioning stuff. He was quite helpful to me when I was working on my book Applied Microsoft .NET Framework Programming (Microsoft Press, 2002), and we immediately became friends. Later, Steve became the program manager responsible for the CLR's hosting capabilities that were added to version 2.0 of the .NET Framework. This, of course, makes Steve uniquely suited to write a book like this. He has the deep knowledge of how the system works and also has the experience of talking to customers to understand their needs and can therefore explain why the CLR team was motivated to add the features they did.

When Steve told me that he wanted to write this book, I immediately asked him if I could review it as he wrote it because I wanted to learn about all this stuff myself. I am very impressed at how good a job Steve has done. Even if you aren't interested in incorporating the CLR into your own applications and servers, this book will offer you insight into how the CLR works that no other book comes close to supplying. If you are familiar with Applied Microsoft .NET Framework Programming, you will find this book to be a great complement to it.

As you read this book, you will gain a different perspective on the CLR that will no doubt give you a new appreciation for it. This book can open your mind to new possibilities of how to use the CLR, and I'm sure that you will get as much out of it as I have.

Jeffrey Richter (http://wintellect.com)