Kevin R. Burton - .NET Common Language Runtime Unleashed

Walking down the aisle of your favorite bookstore, you will find numerous books covering various aspects of Microsoft's new .NET strategy. But unlike most of those books, .NET Common Language Runtime Unleashed focuses squarely on the Common Language Runtime (CLR). Regardless of the language you use or the type of application you are building, .NET Common Language Runtime Unleashed offers a rare insight into how your application and the CLR operate. It offers a perspective that nearly every developer who is using the CLR will find valuable.

What exactly is the CLR? I've spent the past four years explaining that to thousands of developers. From a technical perspective, four key aspects of the CLR make it interesting: the type system (covered in , .NET Security). But from the more practical perspective, the CLR is all about simplicity, making it easier to design, build, integrate, and deploy safe and economical business solutions.

In the years leading up to the development of the CLR, application complexity was growing by leaps and bounds. Each year, a new set of technologies was introduced that added to the complexity of solving business problems. Each new technology added value, but the cumulative effect of all these technological additions became insurmountable for most application developers. Building a typical application was beginning to require a team of highly paid software specialists. The days of programming as a hobby were becoming a distant memory.

Several groups within and outside of Microsoft made attempts to build abstractions over the complexity. MFC, ATL, and Visual Basic 6.0 did a fantastic job of hiding details in exchange for greater developer productivity. But in the end, no single tool, language, or framework could solve every problem. The tools that were designed to make development simpler only contributed to the technology explosion.

To truly simplify development, nothing short of a revolution would suffice. It would take dedication and commitment to come up with a solution that addressed the problem at the most fundamental levels. The solution wouldn't be easy, it wouldn't happen overnight, and certain tradeoffs would be downright painful to face. Some folks would embrace the idea of a fundamental change, whereas others would remain skeptical.

The CLR is a result of that dedication and commitment to making development easier. Creating the CLR was a monumental effort lasting more than four years and requiring the personal devotion of thousands of professional software developers. It sprouted from the vision of a handful of individuals at Microsoft who believed that a better, more productive way to develop software existed, and it grew into the foundation for an entirely new software platform.

Simplicity takes on many forms. It means doing away with some of the complexities that developers have reluctantly learned to live with over timethings like having to define types in IDL as well as the language you use to implement those types, having to deal with various incarnations of common data types like strings and dates, and having to assign globally unique identifiers (GUIDs) to every new data type you define. It also means offloading some of the more mundane coding chores like having to manage object lifetime on your own and having to add code to support late binding or serialization.

The CLR takes a new approach to simplification. It starts at the lowest level by introducing a language-neutral type system that makes type definitions ubiquitous. A type defined using the common type system can be used by a variety of programming languages. More importantly, those languages that target the CLR use the type system natively, thereby eliminating type incompatibilities and unnecessary data transformations. The common type system makes every type look familiar to every type of developer regardless of how the type was created. The common type is the single most important feature of the CLR. Understanding the value of a common type system is key to understanding why the CLR is so important.

Because all types are defined with a common type system, the CLR's execution environment is able to offer a number of runtime services to the objects that a program creates. Services such as lifetime management, dynamic inspection, late-binding support, serialization, and remoting are all made possible by the common type system. Each service that the CLR provides is one less piece of code that developers have to provide and one fewer source of potential bugs.

Another aspect of simplicity involves deployment. In fact, the single biggest cost in building applications today is often the cost of deploying the application to an enterprise. In large organizations, the deployment cost can easily outweigh the cost of actually developing the application. The challenge in deployment is managing the pieces of code that are shared among several applications. As new applications are installed, the shared code is often overwritten with a newer but subtly incompatible version of the shared code. These incompatibilities often lead to problems with other applications that share the same component (a situation commonly referred to as DLL Hell ).

The CLR addresses deployment headaches in several ways. It captures precise details about the shared code on which an application depends. This information (metadata) allows the CLR to identify exactly the code on which an application depends. This precise binding information along with the ability to have multiple versions of shared components installed on the same machine makes application binding much more resilient. It allows multiple applications that depend on different versions of a shared component to coexist peacefully on a user's machine. It also allows developers to evolve types over time without being overly constrained with maintaining backward compatibility.

Concerns about security are a way of life, and software is no different. Security requirements are different for various applications. Application developers need a system that allows them to build highly secure applications and the trivial utilities that know nothing of security. What's difficult is that security isn't an on/off switch; developers also need to be able to build applications with varying degrees of security (partially trusted applications). Key to the CLR security model is the notion that code, as well as users, can have an identity and that decisions of trust made at execution time can be based on the identity of the code and the user. This model is much different from older models that were based solely on the user identity. This model also differs from the Authenticode model, which only comes into play when code is being installed on a user machine.