About this article
The article is an explanation of Assemblies in Visual Studio 2008. The article has been taken from book "Apress C# 2008 Illustrated". The article explains the Structure of an Assembly, Strongly named assemblies and Deployment of Assemblies.
The Structure of an Assembly
an assembly does not contain native machine code, but Common
Intermediate Language (CIL) code. It also contains everything needed by the Just-in-Time (JIT)
compiler to convert the CIL into native code at run time, including references to other assemblies
it references. The file extension for an assembly is generally .exe or .dll.
Most assemblies are composed of a single file. Figure 10-11 illustrates the four main sections
of an assembly.
- The assembly manifest contains the following: – The identity of the assembly name
– A list of the files that make up the assembly
– A map of where things are in the assembly
– Information about other assemblies that are referenced
- The type metadata section contains the information about all the types defined in the
assembly. This information contains everything there is to know about each type.
- The CIL section contains the intermediate code for the assembly.
- The resources section is optional, but can contain graphics or language resources.
The Identity of an Assembly
In the .NET Framework, the filenames of assemblies are not as important as in other operating
systems and environments. What is much more important is the identity of an assembly.
The identity of an assembly has four components that together should uniquely identify it.
These four components are the following:
- Simple name: This is just the filename without the file extension. Every assembly has a
simple name. It is also called the assembly name or the friendly name.
- Version number: This consists of a string of four period-separated integers, in the form
MajorVersion.MinorVersion.Build.Revision—for example, 18.104.22.168.
- Culture information: This is a string that consists of two to five characters representing
a language, or a language and a country or region. For example, the culture name for
English as used in the United States is en-US. For German as used in Germany, it is de-DE.
- Public key: This 128-byte string should be unique to the company producing the
Strongly Named Assemblies
A strongly named assembly is one that has a unique digital signature attached to it. Strongly
named assemblies are much more secure than assemblies that do not have strong names, for
the following reasons:
- A strong name uniquely identifies an assembly. No one else can create an assembly with
the same strong name, so the user can be sure that the assembly came from the claimed
- The contents of an assembly with a strong name cannot be altered without the security
components of the CLR catching the modification.
A weakly named assembly is one that is not strongly named. Since a weakly named assembly
does not have a digital signature, it is inherently insecure. Because a chain is only as strong
as its weakest link, by default, strongly named assemblies can only access other strongly
named assemblies. (There’s also a way to allow “partially trusted callers,” but I won’t be covering
The programmer does not produce the strong name. The compiler produces it by taking
information about the assembly and hashing it to create a unique digital signature that it
attaches to the assembly. The pieces of information it uses in the hash process are the following:
- The sequence of bytes composing the assembly
- The simple name
- The version number
- The culture information
- The public/private key pair
Creating a Strongly Named Assembly
To strongly name an assembly using Visual Studio 2008, you must have a copy of the public/
private key pair file. If you don’t have a key file, you can have Visual Studio generate one for
you. You can then do the following:
- Open the properties of the project.
- Select the Signing tab.
- Select the Sign the Assembly check box and enter the location of the key file.
Private Deployment of an Assembly
Deploying a program on a target machine can be as simple as creating a directory on the
machine and copying the application to it. If the application doesn’t need other assemblies
(such as DLLs), or if the required DLLs are in the same directory, the program should work just
fine where it is. Programs deployed this way are called private assemblies, and this method of
deployment is called xcopy deployment.
Private assemblies can be placed in almost any directory, and are self-sufficient as long as
all the files on which they depend are in the same directory or a subdirectory. In fact, you could
have several directories in various parts of the file system, each with the identical set of assemblies,
and they would all work fine in their various locations.
Some important things to know about private assembly deployment are the following:
- The directory in which the private assemblies are placed is called the application
- A private assembly can be either strongly named or weakly named.
- There is no need to register components in the registry.
- To uninstall a private assembly, just delete it from the file system.
Shared Assemblies and the GAC
Private assemblies are very useful, but sometimes you will want to put a DLL in a central place
so that a single copy can be shared by other assemblies on the system. .NET has such a repository,
called the global assembly cache (GAC). An assembly placed into the GAC is called a shared
Some important facts about the GAC are the following:
- Only strongly named assemblies can be added to the GAC.
- Although earlier versions of the GAC accepted only files with the .dll extension, you
can now add assemblies with the .exe extension as well.
- The GAC is located in a subdirectory named Assembly, of the Windows system directory.
Installing Assemblies into the GAC
When you attempt to install an assembly into the GAC, the security components of the CLR
must first verify that the digital signature on the assembly is valid. If there is no digital signature,
or if it is invalid, the system will not install it into the GAC.
This is a one-time check, however. After an assembly is in the GAC, no further checks are
required when it is referenced by a running program.
The gacutil.exe command-line utility allows you to add and delete assemblies from the
GAC, and list the assemblies it contains. The three most useful flags are the following:
- /i: Inserts an assembly into the GAC
- /u: Uninstalls an assembly from the GAC
- /l: Lists the assemblies in the GAC
Side-by-Side Execution in the GAC
After an assembly is deployed to the GAC, it can be used by other assemblies in the system.
Remember, however, that an assembly’s identity consists of all four parts of the fully qualified
name. So, if the version number of a library changes, or if it has a different public key, these differences
specify different assemblies.
The result is that there can be many different assemblies in the GAC that have the same
filename. Although they have the same filename, they are different assemblies and coexist perfectly
fine together in the GAC. This makes it easy for different applications to use different
versions of the same DLL at the same time, since they are different assemblies with different
identities. This is called side-by-side execution.
As shown in the image below, these versions differ as follows:
- An English version 22.214.171.124, from company A
- An English version 126.96.36.199, from company A
- A German version 188.8.131.52, from company A
- An English version 184.108.40.206, from company B