Assemblies in the .Net platform

Assemblies in the .Net platform are a solution to a problem that has been around as long as libraries. The problem, known as "DLL Hell", can be caused by one application overwriting a shared library of another application, usually with a different version.

Imagine you write an application with a shared library and then years later create a new application with an updated library. In order not to break old programs, what do you do with the new library? You could give it a different name, store it in a different location, or overwrite the old ones?

Problems can also arise when a DLL is registered on a computer and for some reason the information is corrupted or modified so that the reference no longer links to the library. Registering a DLL in the system registry stores information about that library in sucha a way that other applications can access the data from a central store.

.Net assemblies overcome these issues by storing information about themselves, rather than having that information stored in a central location. The assembly will hold information about itself such as version and vendor.

Microsoft has defines an assembly and its role in .NET as:

In the .NET Framework an assembly is the physical unit that can be executed, deployed, versioned, and secured. All .NET Framework applications contain one or more assemblies.

Versioning
The platform will assist you by providing a number of features to ensure proper versioning between components in an application:

Enforce versioning rules so that an application that needs version 1.1.1.1 will not end up getting version 1.0.0.0.
Shared assemblies are signed with a strong name (which includes a public key, a simple name, a version, and a culture) to make them unique. Assemblies that are not shared do not require strong names.
The information that the assembly holds about itself is called the metadata which is stored in the manifest. The manifest is like the unique fingerprint of the assembly.

We will cover strong names in more detail when we look at security.

Deployment
We will look at assembly deployment in further detail in a later section, but to give an overview assemblies can be deployed in one of three ways – direct file copy (xcopy), Windows Installer setup projects and Merge Modules setup project.

To directly copy an assembly all you need to do is copy the file to the applications executable or bin folder and it is available to use, however this can only be done with a private assembly. Shared assemblies need to be installed to the machines Global Assembly Cache (GAC) using the gacutil tool or by copying the assembly to the GAC folder within Windows explorer. Installation in the GAC results in a uniquely named folder being created and the assembly files being copied into that folder.

Windows installer and merge module projects will perform the installation for the user and is the recommended method for deployment.

What Is in the Assembly?
The assembly contains the intermediate code, resources, and the metadata for itself. We can have a look inside the assembly using the ildasm (Intermediate Language Disassembler) tool that comes as part of Visual Studio. To access it you need to open the Visual Studio Command Prompt and type ildasm.exe. This will launch a Windows application that you can use to explore any .Net application.

Once launched, you can open any .Net application and view information within the file, including the manifest, types, classes, namespaces, methods and source code.

When we look at security in a later section we will look into methods for protecting your assemblies so that they cannot be disassembled in this manner.