Assemblies in .Net

Assemblies can be thought of as the building blocks of your applications.

Without an associated assembly, code will not be able to compile from IL.
As in the Windows DNA world where DLLs and EXEs are the building blocks of applications,

in the .NET world, it is the assembly that is the used as the foundation of applications.
With .NET, it is now possible to have multiple versions of components, or assemblies, running

on the same server side by side. An application will always look for the assembly that built it.
When an application is started in .NET, the application will look for an assembly in the

installation folder. Assemblies that are stored in a local installation folder are referred to as
private assemblies. If the application cannot find the assembly within the installation folder,
the application will turn to the Global Assembly Cache (GAC) for the assembly.

The structure of an assembly

Assemblies contain code that is executed by the Common Language Runtime. The great thing

about assemblies is that they are self-describing.

Assemblies are made up of the following parts:

• The assembly manifest
• Type metadata
• Microsoft Intermediate Language (MSIL) code

The assembly manifest is where the details of the assembly are stored. The assembly is stored
within the DLL or EXE itself. Assemblies can either be single or multifile assemblies and,
therefore, assembly manifests can either be stored in the assembly or as a separate file. The
assembly manifest also stores the version number of the assembly to ensure that the
application always uses the correct version. When you are going to have multiple versions of
an assembly on the same machine, it is important to label them carefully so that the CLR
knows which one to use.