.NET Assembly Features

Before looking at the structure of an assembly, let's discuss some of the features of .NET assemblies.

Self-Description

The most important aspect of .NET assemblies, which distinguishes them from their predecessors, is that they are fully self-describing. The description is contained within the assembly, so the system or calling program does not have to look up information in the Registry or elsewhere about the objects contained within the assembly.

The self-description of .NET assemblies goes beyond names of objects and methods, and the data types of parameters; it also includes information about what version the objects are (think of Shapes 1.0 followed by Shapes 1.1 or Shapes 2.0), and controls the security for the contained objects. All of this information is contained within the assembly itself — there is no need to look up information elsewhere. This makes installation of a .NET component much easier and more straightforward than with the existing Windows technologies. In fact, it can be literally as easy as copying the assemblies onto the disk of the target system.

.NET Assemblies and the .NET Framework Class Library

Every .NET program, including all C# programs, makes extensive use of the .NET Framework Class Library. You are using these classes whenever you call a method from the the System namespace with the using System directive — all the System namespaces (System.Data, System.Drawing, and so on) belong to the .NET Framework Class Library.

Each class within this library is part of a self-describing assembly. The drawing classes, for example, are contained in the System.Drawing.dll assembly. If you add a reference to this assembly in Visual Studio 2005, the compiler will include a reference to that assembly when it builds the assembly for your program. At runtime, the CLR reads the metadata in your program's assembly to see what other assemblies it needs, then locates and loads those assemblies for your program to use. Assemblies referenced by your program may reference other assemblies, so that even a simple program with a single using directive may actually reference several different assemblies. The self-description in each assembly keeps track of all these references, without you having to be aware of it.

I should clarify something here so as to not cause confusion later on.

Important

The correspondence between namespaces and assemblies is not necessarily one-toone. In other words, an assembly may contain information from more than one name- space, and conversely, a single namespace may be spread across several assemblies.

For example, the System.Data.dll assembly actually contains some functionality from both the System.Data and System.Xml namespaces, while other functionality in the System.Xml namespace is implemented in the System.Xml.dll assembly. Within your program, you are referring to a namespace when specifying the using directive; the references in your Visual Studio 2005 project specify the actual assemblies used.

Cross-Language Programming

One additional benefit of assemblies and .NET is that they enable cross-language programming, since components can be called from any .NET language, regardless of the language they were originally written in.

.NET provides a number of features that enable cross-language programming:

• The Common Language Runtime (CLR), which manages the execution of all .NET assemblies.

• MSIL (Microsoft Intermediate Language), generated by all the .NET language compilers. This is a common standard for the binary code generated by the compilers and is what is executed by the CLR. The CLR also defines the format for storing an assembly's metadata, and this means that all assemblies, whatever language they were written in, share a common format for storing their metadata.

• The Common Language Specification (CLS), provided so that programs written in C#, the .NET versions of Visual Basic and Visual C++, or any other .NET language that is CLS-compliant can share components with full inheritance across language boundaries. The CLS defines the features that languages must support in order to support interoperability with other .NET languages. It is possible to use features that are not in the CLS, but there is no guarantee that these will be supported by other languages.

The Common Type System (CTS), which defines the basic types used by all .NET languages and rules for defining your own classes. This prevents languages implementing, say, the String type in incompatible ways.

By following the CLS specification, you can write a component in C#, and the assembly containing the component can be used by a program written in another .NET language, such as Visual Basic .NET, because both the C# and Visual Basic .NET components will be executed by the CLR. Similarly, C# programs can use components written in Visual Basic .NET, Visual C++.NET, and so on. At the assembly level, all classes, objects, and data types used by .NET languages are shared, so you can inherit classes and make full use of components no matter what language they are written in.

Interoperation with COM and Other Legacy Code

the .NET Framework also allows components or libraries written using COM and other legacy technologies to be used with C# and other .NET languages.

This mechanism also works via self-describing assemblies. A wrapper assembly is created for the legacy code that allows it to describe itself to the .NET runtime and convert the COM data types to .NET data types, and allows calls back and forth from the .NET languages to the legacy code and vice versa. Visual Studio 2005 automatically creates a wrapper assembly when you add a reference to a COM component (using the COM tab in the Add Reference dialog).

This diagram shows such a wrapper (also called a Runtime Callable Wrapper) in use. Calls made by the .NET client assembly go through the wrapper to get to the COM component. From the .NET assembly's point of view, the wrapper is the component, as shown in Figure 26-1.

Figure 26-1

There are difficulties in interoperating with legacy technologies such as COM, but that subject is beyond the scope of this book.