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.

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

When to Delay Sign Assemblies

In a workplace where many developers are working on a project, there is every possibility of
private key of assembly being mishandled. Hence in a development environment, it
becomes mandatory to maintain the integrity of the system during tests and build. This is
where delay signing proves significant.

What is Delay Signing?

Delay signing is a process of generating partial signature during development with access
only to the public key. The private key can be stored securely and used to apply the final
strong name signature just before shipping the project.

How to delay sign assemblies?

To use delay signing, follow these five steps:

1. Extract the public key from the key pair. We can use the tool sn.exe for this.

sn - pc keypairfilename ExtractPublicKey.pk

2. The generated public key (ExtractPublicKey.pk) can be used by development team to

delay sign assemblies. This is a stage when .NET Framework will not allow us to load
the delay-signed assemblies as they are yet not fully signed. Hence it becomes vital
to configure our development machines such that it skips strong name signature
verification for our key.

Use C# compiler to delay sign assembly as follows:

csc /delaysign+ /keyfile: ExtractPublicKey.pk test.cs

3. To configure the .NET Framework to skip strong name signature verification for the
test.exe assembly on development machines:

sn - Vr test.exe

We can also configure our machine to skip all assemblies delay signed with the same
 key as test application. The following command will do this:

sn - T test.exe

The execution of above command will give us the public key token.

Public key token is b03f5f7f11d50a3a

4. Execute the following command to skip strong name verification for any assembly
using the public key token generated above:

sn - Vr *,b03f5f7f11d50a3a

Please note that skipping strong name signature verification is something that should
only be done on development machines. It should never be done in production
environment as it opens up those machines to assembly spoofing attacks.

5. The fifth step is the final step taken before the deployment of the project to the
production. We will use the securely saved private key to generate the final full
strong name with sn.exe tool. 

sn - Rc test.exe keypairfilename

This completes the process and adds the full signature to the assembly. A pointer to
this step is that our delay-signed assemblies now don't need to be rebuilt. Any
assemblies that had a reference to the delay-signed assembly also had access to its
public key and are therefore able to create a full assembly reference, even though
the assembly did not have a full signature.

Summary

Delay signing the assemblies is a easy and secure way of protecting the assemblies in the
development environment. However please note that with delayed signing on, during testing
environment none of the strong name signatures are verified.