The Common Language Runtime

We are all familiar with runtimes - they go back further than DOS languages. However, the common language runtime (CLR) is as advanced over traditional runtimes as a machine gun is over a musket. Figure 1-2 shows a simple diagrammatic summary of the major pieces of the CLR.

Common Type System Data Types, etc.
Intermediate Language (IL) to native code compilers	Execution Support (traditional runtime functions)	Security
Garbage collection, stack walk, code manager
Class loader and memory layout

Open table as spreadsheet

Figure 1-2

Key Design Goals

The design of the CLR is based on the following primary goals:

• Simpler, faster development

• Automatic handling of system-level tasks such as memory management and process communication

• Excellent tool support

• Simpler, safer deployment

• Scalability

Many of these design goals directly address the limitations of COM. Let’s look at some of these in detail.

Simpler, Faster Development

A broad, consistent framework enables developers to write less code, and to reuse code more. Using less code is possible because the system provides a rich set of underlying functionality. Programs in .NET access this functionality in a standard, consistent way, requiring less “hardwiring” and customization logic to interface with the functionality than was typically needed in earlier platforms. Programming is also simpler in .NET because of the standardization of datatypes and interface conventions.

The result is that programs written in VB 2005 that take proper advantage of the full capabilities of the .NET Framework typically have significantly less code than equivalent programs written in pre-.NET versions of Visual Basic. Less code means faster development, fewer bugs, and easier maintenance.

Excellent Tool Support

Although much of what the CLR does is similar to operating system functionality, it is very much designed to support development languages. It furnishes a rich set of object models that are useful to tools such as designers, wizards, debuggers, and profilers; and because the object models are at the runtime level, such tools can be designed to work across all languages that use the CLR. Many such tools are available from a variety of third-party vendors.

Simpler, Safer Deployment

Applications produced in the .NET Framework can be designed to install with a simple XCOPY. Just copy the files onto the disk and run the application (as long as the .NET Framework is already available on the machine). There are other more sophisticated deployment possibilities, but most rely on .NET’s simple deployment model.

This model works because compilers in the .NET Framework embed identifiers (in the form of metadata, to be discussed later) into compiled modules, and the CLR manages those identifiers automatically. The identifiers provide all the information needed to load and run modules, and to locate related modules.

As a great by-product, the CLR can manage multiple versions of the same component (even a shared component) and have them run side by side. The identifiers tell the CLR which version is needed for a particular compiled module, because such information is captured at compile time. The runtime policy can be set in a module either to use the exact version of a component that was available at compile time, to use the latest compatible version, or to specify an exact version.

This has implications that might not be apparent at first. For example, .NET supports a program that can run directly from a CD or a shared network drive, without first running an installation program. This dramatically reduces the cost of deployment in many common scenarios.

Another significant deployment benefit in .NET is that applications only need to install their own core logic. An application produced in .NET does not need to install a runtime, for example, or modules for ADO or XML. Such base functionality is part of the .NET Framework, which is installed separately and only once for each system. As mentioned earlier, the .NET Framework 3.0 is included with the Windows Vista operating system, and can be installed on a one-time basis on Windows XP and Windows 2003 Server.

.NET programs can also be deployed across the Internet. Version 3.0 of the .NET Framework includes a technology specifically for that purpose called ClickOnce. This was a new capability in .NET 2.0, supplementing the “no touch deployment” of earlier versions. You can read about ClickOnce in Chapter 22.

Scalability

Since most of the system-level execution functions are concentrated in the CLR, they can be optimized and architected to allow a wide range of scalability for applications produced in the .NET Framework. As with most of the other advantages of the CLR, this one comes to all applications with little or no effort.

Memory and process management is one area where scalability can be built in. The memory management in the CLR is self-configuring and tunes itself automatically. Garbage collection (reclaiming memory that is no longer being actively used) is highly optimized, and the CLR supports many of the component management capabilities of COM+ (such as object pooling) in a portion of .NET called Enterprise Services. The result is that components can run faster and, thus, support more users.

This has some interesting side effects. For example, the performance and scalability differences among languages become smaller. All languages compile to a standard byte code called Microsoft Intermediate Language (MSIL), often referred to simply as IL. With all languages compiling down to similar byte code, it becomes unnecessary in most cases to look to other languages when performance is an issue. The difference in performance among .NET languages is minor - Visual Basic, for example, offers about the same performance as any of the other .NET languages.

Versions of the CLR are available on a wide range of devices. The vision is for .NET to be running at all levels, from smart mobile devices all the way up to Web farms. The same development tools work across the entire range. (The current version of .NET for mobile devices is still based on .NET Framework 2.0, but Visual Studio 2005 can still work with that version, which is known as the Compact Framework.)

Metadata

The .NET Framework needs a lot of information about an application to carry out several automatic functions. The design of .NET requires applications to carry that information within them. That is, applications are self-describing. The collected information that describes an application is called metadata.

The concept of metadata is not new. For example, COM components use a form of it called a type library, which contains metadata describing the classes exposed by the component and is used to facilitate OLE Automation. A component’s type library, however, is stored in a separate file. In contrast, the metadata in .NET is stored in one place - inside the component it describes. Metadata in .NET also contains more information about the component and is better organized.

Chapter 5, “The Common Language Runtime,” provides more information about metadata, and Chapter 21, “Assemblies,” has additional detail. For now, the most important point for you to internalize is that metadata is key to the easy deployment in .NET. When a component is upgraded or moved, the necessary information about the component cannot be left behind. Metadata can never become out of sync with a .NET component because it is not in a separate file. Everything the CLR needs to know to run a component is supplied with the component.

Multiple-Language Integration and Support

The CLR is designed to support multiple languages and allow high levels of integration among those languages. By enforcing a common type system, and by having complete control over interface calls, the CLR enables languages to work together more transparently than ever before. The cross-language integration issues of COM simply don’t exist in .NET.

It is straightforward in the .NET Framework to use one language to subclass a class implemented in another. A class written in Visual Basic can inherit from a base class written in C#, or in a .NET version of COBOL for that matter. The VB program doesn’t even need to know the language used for the base class. .NET offers full implementation inheritance with no problems that require recompilation when the base class changes.

A Common Type System

A key piece of functionality that enables multiple-language support is a common type system, in which all commonly used datatypes, even base types such as Long and Boolean, are actually implemented as objects. Coercion among types can now be done at a lower level for more consistency between languages. In addition, because all languages are using the same library of types, calling one language from another doesn’t require type conversion or weird calling conventions.

This results in the need for some readjustment, particularly for developers who are only familiar with pre-.NET versions of VB. For example, what was called an Integer in VB6 and earlier is now known as a Short in VB 2005.

The “everything’s an object” approach of .NET results in other potential surprises. For example, because String is a class in .NET instead of just a simple datatype, it has methods for string manipulation. Splitting a string into parts based on a delimiter is done with the String.Split method. VB6 developers might expect there to be a language keyword or a function in the library to do this, and wouldn’t necessarily expect a method call right on the String object.

These adjustments are well worth the effort. The benefit is the ascension of Visual Basic to the status of a fully object-oriented language with no “glass ceiling” preventing it from being used for scenarios such as creating visual controls.

The CLR enforces the requirement that all datatypes satisfy the common type system. This has important implications, too. For example, it is not possible with the common type system to get the problem known in COM as a buffer overrun, which is the source of many security vulnerabilities. Programs written on .NET should have fewer such vulnerabilities because .NET is not dependent on the programmer to constantly check passed parameters for appropriate type and length. Such checking is done by default.

Chapter 2 goes into detail about the new type system in .NET.

Namespaces

One of the most important concepts in the .NET Framework is namespaces. Namespaces help organize object libraries and hierarchies, simplify object references, prevent ambiguity when referring to objects, and control the scope of object identifiers. The namespace for a class enables the CLR to unambiguously identify that class in the available .NET libraries that it can load.

Namespaces are discussed briefly in Chapter 2 and in more detail in Chapter 8. Understanding the concept of a namespace is essential for your progress in .NET, so do not skip those sections if you are unfamiliar with namespaces.