An assembly can consist of the following four elements:
- Your code, compiled into MS intermediate language (MISL). This code file can be either an EXE file or a DLL file.
- The assembly manifest, which is a collection of metadata that describes assembly name, culture settings, list of all files in the assembly, security identity, version requirements, and references to resources. The assembly manifest can be stored with the intermediate code, or in a standalone file that contains only assembly manifest information.
- Type metadata
- Resources
As we have mentioned above, an assembly can be formed into a single physical file. In this case all the above four elements will be stored inside this file (either an EXE, or a DLL file). Or it can be formed in more than one file, and in this later case we call it a multi-file assembly. In multi-file assembly the above four elements can be stored in separate files like module files for code, resources files for images, or other files required by the application. Note that the files that forms the multi-file assembly are not physically linked, instead they are linked through the assembly manifest.
Assemblies are mainly introduced to solve the problems of versioning, DLL conflicts, and simplifying the process of deployment.
Most end users have encountered versioning or deployment problems when they do install a new application or a new version of an existing one. There are many situations where you install a new application only to find an existing one stopped working, and the system can not recover from that. Many developers spent a lot of time trying to retain the registry entries consistence in order to activate a COM class. All this frustration occurs because of versioning problems that occur with component-based applications.
Versioning Problems
There are two versioning problems that arise with WIN32 applications. The first one is that versioning rules are enforced by the operating system not between the pieces of an application. Backward compatibility between the new piece of code and the old one is the current approach of versioning and this is hard to maintain in most applications. Beside that only a single version of an application is allowed to be present and executing on a computer at any given time. The second problem is that there is no way to preserve consistency between groups of components that are built together and the current present group at run time.
An assembly can have two types of versions. The first one which we call "Version Number" consists of a four-part string with the following format:
<Major Version>.<Minor Version>.<Build Number>.<Revision Number>
DLL Conflicts
As a result of the above two versioning problems, DLL conflicts do occur. Which is: when installing a new application an existing one may break because of that the new one installed a new version of a component or a DLL that is not fully backward compatible with the previous one.
Assembly Locations
An assembly can be placed into one of the following three locations:
- Under the application directory or subdirectories. This is the most common location for placing an assembly. If your assembly uses a culture other than the default one which is "en-US", you have to put it under a subdirectory with this culture name.
- In the global assembly cache, which is a machine code cache installed whenever the common language runtime is installed. You deploy your assembly to the global assembly cache when you want to share it with multiple applications.
- On an ftp server.