<%@ Page %>
Introduction to .NET Assemblies
You must have heard the word assembly many times in .NET documentation. In this article I will share some thing about .NET assemblies.
What is an assembly?
- An Assembly is a logical unit of code
- Assembly physically exist as DLLs or EXEs
- One assembly can contain one or more files
- The constituent files can include any file types like
image files, text files etc. along with DLLs or EXEs
- When you compile your source code by default the
exe/dll generated is actually an assembly
- Unless your code is bundled as assembly it can not be
used in any other application
- When you talk about version of a component you are
actually talking about version of the assembly to which the component belongs.
- Every assembly file contains information about itself. This
information is called as Assembly Manifest.
What is assembly manifest?
- Assembly manifest is a data structure which stores
information about an assembly
- This information is stored within the assembly
file (DLL/EXE) itself
- The information includes version information, list of constituent files etc.
What is private and shared assembly?
The assembly which is used only by a single application is called as private assembly.
Suppose you created a DLL which encapsulates your business logic. This DLL will be used by
your client application only and not by any other application. In order to run the
application properly your DLL must reside in the same folder in which the client
application is installed. Thus the assembly is private to your application.
Suppose that you are creating a general purpose DLL which provides functionality which
will be used by variety of applications. Now, instead of each client application having
its own copy of DLL you can place the DLL in 'global assembly cache'. Such assemblies are
called as shared assemblies.
What is Global Assembly Cache?
Global assembly cache is nothing but a special disk folder where all the shared
assemblies will be kept. It is located under <drive>:\WinNT\Assembly folder.
How assemblies avoid DLL Hell?
As stated earlier most of the assemblies are private. Hence each client application
refers assemblies from its own installation folder. So, even though there are multiple
versions of same assembly they will not conflict with each other. Consider following
- You created assembly Assembly1
- You also created a client application which uses
Assembly1 say Client1
- You installed the client in C:\MyApp1 and also placed
Assembly1 in this folder
- After some days you changed Assembly1
- You now created another application Client2 which uses
this changed Assembly1
- You installed Client2 in C:\MyApp2 and also placed changed Assembly1 in this
- Since both the clients are referring to their own versions of Assembly1 everything goes
Now consider the case when you develop assembly that is shared one. In this case it is
important to know how assemblies are versioned. All assemblies has a version number in the
If you change the original assembly the changed version will be considered compatible
with existing one if the major and minor versions of both the assemblies match.
When the client application requests assembly the requested version number is matched
against available versions and the version matching major and minor version numbers and
having most latest build and revision number are supplied.
How do I create shared assemblies?
Following steps are involved in creating shared assemblies :
- Create your DLL/EXE source code
- Generate unique assembly name using SN utility
- Sign your DLL/EXE with the private key by modifying AssemblyInfo file
- Compile your
- Place the resultant DLL/EXE in global assembly cache using AL utility
How do I create unique assembly name?
Microsoft now uses a public-private key pair to uniquely identify an assembly. These
keys are generated using a utility called SN.exe (SN stands for shared name). The most
common syntax of is :
sn -k mykeyfile.key
Where k represents that we want to generate a key and the file name followed is the
file in which the keys will be stored.
How do I sign my DLL/EXE?
Before placing the assembly into shared cache you need to sign it using the keys we
just generated. You mention the signing information in a special file called AssemblyInfo.
Open the file from VS.NET solution explorer and change it to include following lines :
Now recompile the project and the assembly will be signed for you.
Note : You can also supply the key file
information during command line compilation via /a.keyfile switch.
How do I place the assembly in shared cache?
Microsoft has provided a utility called AL.exe to actually place your
assembly in shared cache.
Now your dll will be placed at proper location by the utility.
Now, that we have understood the basics of assemblies let us apply our knowledge
by developing a simple shared assembly.
In this example we will create a VB.NET component called SampleGAC
( GAC stands for Global Assembly Cache). We will also create a key
file named sample.key. We will sign our component with this key
file and place it in Global Assembly Cache.
- Step 1 : Creating our sample component
Here is the code for the component. It just includes one method which returns
public class Sample
public function GetData() as string
return "hello world"
- Step 2 : Generate a key file
To generate the key file issue following command at command prompt.
sn -k sample.key
This will generate the key file in the same folder
Now, wee will sign the assembly with the key file we just created.
vbc sampleGAC.vb /t:library /a.keyfile:sample.key
We will use AL utility to place the assembly in Global Assembly Cache.
After hosting the assembly just go to
WINNT\Assembly folder and you will find your assembly listed there. Note how the assembly folder
is treated differently that normal folders.
Click here to view
the screen shot
Now, we will create a sample client application which uses our
shared assembly. Just create a sample code as listed below :
public class SampleTest
shared sub main()
dim x as new sample
dim s as string=x.getdata()
Compile above code using :
vbc sampletest.vb /t:exe /r:<assembly_dll_path_here>
Now, copy the resulting EXE in any other folder and run it. It will display
"Hello World" indicating that it is using our shared assembly.
I hope you must have got some idea about .NET assemblies. If you have some thing interesting to add or share drop a line at firstname.lastname@example.org