Foreword

Working on the Common Language Runtime (CLR) for the past three-and-a-half years has been a fantastic opportunity. It’s not often that you get the chance to work on a project where you can forget about the past and design an exciting new set of technologies from the ground up, uninhibited by the constraints of maintaining backward compatibility.

The CLR offers a fresh solution to the problems developers face in building and using reusable components and deployable applications. It’s an entirely new architecture aimed squarely at simplifying the development and deployment process. In designing the CLR we took the opportunity to step back and look at the process of writing reusable components using COM today. We examined the problems people had with things like reference counting, apartments, and registration, and we looked at the aspects of the model that made building COM components complicated. One of the primary design goals in building the CLR was to eliminate that complexity. In short, it was time to make programming fun again.

COM was nothing short of revolutionary when it was first introduced. It provided a standard mechanism with which developers could build reusable components. Most developers like to forget about the pre-COM days, when linking to static DLL exports was about as close as you could get to reusability. Over the years, the popularity of COM has grown enormously, to the point where today, just about every application that provides any level of extensibility does so using COM. But as features were added, the complexity of COM has grown. After nearly ten years of COM enhancements, that complexity reached the point where it began to seriously impede developer productivity.

In some ways, COM is like your 1994 Ferrari. When you first sat in the driver’s seat, you thought it was the greatest, but after a few years, the novelty wore off, and all you focus on is that rattle under the hood and the grinding in the transmission when you try to shift into third gear. After programming with COM for several years, joining the CLR team was like an opportunity to build a new Ferrari, with cool new features that promised to make driving fun again. We had the talent, we had the resources, and we had a 1994 Ferrari sitting in the garage for reference. Most importantly, we had management-level support to build the best darn Ferrari we possibly could. There was only one catch—not everyone could afford a new Ferrari, and even those who could were sometimes a bit skeptical of all the new features. After all, most of the older models were still working pretty well, as long as you stayed out from under the hood.

Surprisingly, some people were actually interested in buying parts of the new Ferrari to use in older models rather than buying a whole new car. And believe it or not, some people loved the old-style Ferrari so much they even wanted to put old parts on the new cars. It seemed that no matter how cool the new model was, there was always someone asking, “Will I be able to take that transmission and put it in my ‘94 Ferrari?” Here we were designing this fabulous new machine, and all people could think about was backward compatibility. (Well, that may not be exactly how it went, but it’s not far off.)

Faced with these requests for compatibility, we formed the Interoperability team within the CLR, whose role it was to build a bi-directional bridge between COM and .NET. Wherever possible, we ignored compatibility constraints in designing the features of the CLR so that we could use the best possible design. Once the feature was designed, the Interop team was faced with the task of bridging the features between .NET and COM. In most cases, the Interop team was able to build the bridge without affecting the initial design. In rare cases (such as enumerations), the interoperability constraints forced us to change the original design for better backward compatibility.

Designing, building and testing this Interop bridge was no small task. It required talented people who had both COM and .NET expertise. Of those involved, Adam Nathan, author of this book, was one of the most talented and important players. Adam joined the team early in the process as a member of the Interop test team. If you had access to the RAID database we use to track bugs, you’d find that Adam has filed a whopping 2022 bugs since the project started (and he’s not done yet). That’s more bugs than anyone else on the entire team. These weren’t trivial bugs, and an amazing 1873 of them were resolved “fixed.” Getting a bug fixed is the equivalent of a base hit for a tester; if Adam played for the Seattle Mariners, he’d be batting .926 (that’s even better than Ichiro). Equally impressive is how few bugs Adam opened that were resolved “by design”—only 44 bugs, or two percent of the total. From a program manager’s perspective, Adam is the kind of test developer you wish you could have on your team.

On top of that, Adam has made numerous contributions to the design of Interop. There was more than one occasion when Adam pointed out flaws in the design that sent developers and program managers back to the garage with their tails between their legs. Consider that Adam did all of this while writing this book in his spare time—during his first year of marriage—and I think you’ll agree that he’s truly an authority when it comes to COM Interop and the CLR. I know of no one who could have done a finer job writing this book than Adam.

Dennis Angeline

Lead Program Manager

Microsoft .NET Common Language Runtime