.NET Framework Assemblies

What Is It?

The 'Assembly' is a new concept that the .NET framework introduces to make your journey in programming more easier. The .NET framework introduces assemblies as the main building blocks of your application. An application can contains one or more assemblies. An assembly can be formed in one or more files. This all depends on your programming needs.

An assembly can consist of the following four elements:

1. Your code, compiled into MS intermediate language (MISL). This code file can be either an EXE file or a DLL file.
2. 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.
3. Type metadata
4. Resources

The main and only required element of the above four elements is the assembly manifest. The remaining elements are optional depending on your requirements.

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.

You may ask yourself, when should I use multi-file assembly technique? The answer is, you should use this form of assembly when you want to combine modules written in different languages, when you want to optimize downloading an application that consists of more than one module, or when you want to use a huge resource file so you put it in a separate resource file and the .NET framework will download it only when it is referenced which will optimize your memory usage and system resources.

Now to the most important part of our tutorial:

What Are the Benefits of Using Assemblies?

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.

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.

The Solution

To solve the above problems, Microsoft began a new approach in its Windows 2000 platform. Windows 2000 gives you the ability to place DLL files used by your application in the same directory as your application's exe file, so that your application can use the right version it was designed for using. Beside that, Windows 2000 locks files that exist in the System32 directory to prevent their replacement when  new applications are installed, and this prevents the DLLs that are used by existing applications from being replaced and so prevents the crashing of existing applications.

The .NET framework introduces assemblies as an evolution towards the complete solution of versioning problems and DLL conflicts. Assemblies on their core design give developers the ability to specify version rules between components, offer the infrastructure required to enforce these rules, and allowing multiple versions of the component to be run side by side at the same time.

How Does It Work?

You may recall that an assembly manifest contains the versioning requirements of the current assembly. The version of the assembly and the versions of the required assemblies and/or components are recorded in the manifest. So, when you run an application, the .NET runtime checks the assembly manifest of your application and executes the version of assemblies or components that are recorded in the manifest. To gain the advantages of versioning you must give your assembly a strong name (will be explained later).

Assembly Version

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>

For example a version number of 3.5.20.1 indicates 3 as the major version, 5 as the minor version, 20 as the build number, and 1 as the revision number.

Note that the version number is stored in the assembly's manifest.

The second type of versions is called "Informational Version". The informational version consists of a string that contains the version number besides additional information like packaging, marketing literature, or product name. This type of version is used for informational purposes only, and is not used at runtime for calculating versioning related decisions.

Assemblies Naming Conventions and Locations

Assembly Names

Each assembly has a name as a part of its identity. You can edit that name by clicking the Project/Properties menu item in the Visual Studio 2005 main menu bar. Select the "Application" tab from the properties window, and you will find a text box that represents the assembly name as shown in the following figure.

1 - You can edit your assembly name from here.

Unfortunately this name is not enough to give a unique identity to a given assembly. To give an assembly a unique identity we use what we call a strong name. A strongly named assembly has a fully qualified name that consists of the assembly's name, culture, public key, and version number. The runtime uses this strong name to identify a referenced assembly, and to differentiate it from the other assemblies.

The following is an example of a strong name of an assembly called "MyAssembly":

        MyAssembly, Version=3.5.20.1, Culture="en-US", 

        PublicKEtToken = b77a5c561934e089c

You can also sign an assembly with a strong name to ensure that it is globally unique.

Assembly Locations

An assembly can be placed into one of the following three locations:

1. 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.

2. 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.

3. On an ftp server.

The location of an assembly determines whether the common language runtime can locate it when it is referenced, and whether this assembly can be shared with other applications or not.

.Net assembly protection

You need to know that every .Net assembly can be easily decompiled by using one of the many free .Net decompilers. In short, if your user have access to your binaries, exe or dll files, practically he or she also have an access to your source code. This problem can be solved with different tools. To protect our .Net applications and custom controls, we use Spices.Net.

For further information

Refer to the online copy of Microsoft Developers Network at http://msdn.microsoft.com or use your own local copy of MSDN.