Introduction
to .NET Assemblies
Click here to download
Introduction
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 example :
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 folder
Since
both the clients are referring to their own versions of Assembly1
everything goes on smoothly
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 form:
major.minor.build.revision
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 DLL/EXE
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 :
[assembly:AssemblyKeyFile("file_path")]
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.
AL
/i:my_dll.dll
Now
your dll will be placed at proper location by the utility.
Hands On...
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 a string.
imports system
namespace BAJComponents
public class Sample
public
function GetData() as string
return "hello world"
end function
end class
end namespace
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
Step
3 : Sign your component with the key
Now,
wee will sign the assembly with the key file we just created.
vbc sampleGAC.vb
/t:library /a.keyfile:sample.key
Step
4 : Host the signed assembly in Global Assembly Cache
We
will use AL utility to place the assembly in Global Assembly Cache.
AL /i:sampleGAC.dll
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
Step
5 : Test that our assembly works
Now,
we will create a sample client application which uses our shared
assembly. Just create a sample code as listed below :
imports system
imports BAJComponents
public class SampleTest
shared sub
main()
dim x as new sample
dim s as string=x.getdata()
console.writeline(s)
end sub
end class
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.
1
0 comments:
Post a Comment