Overview This article is the first part of a three part series of articles covering the .Net assemblies.

In Part 1, I will cover what exactly an assembly is, and what an assembly contains. Part 2 of the series will discuss both Private and Shared assemblies and how to create a "Shared Assembly". I will briefly mention some of the utilities available for working with assemblies. Part 3 will discuss in more detail than Part 2, the details of the available utilities for manipulating assemblies. What is a .NET Assembly? An assembly is a core part of the runtime. An assembly is the collection of all information required by the runtime to execute your application. This information is referred to as the Metadata. An assembly can be a DLL file or a Portable Executable (PE) file. The Common Language Runtime (CLR) can only execute code in assemblies and the assembly must include a manifest or reference a manifest contained in another file. An assembly that has been compiled into a portable executable (PE) file has an extension of AppName.exe. A common mistake made by new comers to the .NET Framework is they think this *.exe file is the same as a standalone executable created by many other languages such as a C++ compiler. There are very big differences between a C++ executable file and a .NET PE file. The PE assembly consists of code in the form of Intermediate Language (IL). This IL code requires the .NET platform be installed on the host in order to run. What is the purpose of an Assembly? An assembly controls many aspects of an application. The assembly handles versioning, type and class scope, security permissions, as well as other metadata including references to other assemblies and resources. The rules described in an assembly are enforced at runtime. Contents of an Assembly

Manifest: The metadata describing the information below. Assembly name: Aids in versioning and visibility scope. Version information: The version number is integrated into the assembly's identity. Types: Boundaries and scopes of methods, classes, properties, events, attributes. Locale: Information describing language/culture. Cryptographic Hash: Public key encoded hash acting as version/security check. Security Permissions: The permissions within the assembly determine the permissions that can be granted for all aspects of the assembly contents.

The Assembly Menifest

All assemblies have a manifest. This manifest may be immediately contained within the assembly as in a single file assembly, or may be referenced in a separate file as in multi file assemblies. The manifest contains information about all portions considered as part of the assembly itself. The information in the manifest is known as the Metadata. The manifest contains information that determines which components are visible beyond the assembly's namespace and also which components are to remain private to the assembly (Scope). Other optional information can be found in the manifest such as configuration information, information about your company or copyright. The manifest contains so much information that usually an assembly can simply just be copied as a whole from one .NET framework to another without having to register with the destination operating system. The Cryptographic Hash This hash contains information such as references to all separate files that are referenced by the assembly, and references to other assemblies that are part of this assembly. The hash is encrypted using public key cryptography. This will be covered more in Part 2 of this article series. The hash is used at runtime to verify that all related files and assemblies have not been modified since the assembly was compiled. This helps prevent unwanted tampering. What is the Assembly Cache? When the .NET SDK is installed, the framework creates a folder on the system. This folder is known as the Assembly Cache. The cache contains a Private section as well as a Global section. The global cache is home to assemblies that are shared. I will cover "Shared Assemblies in Part 2. Specific restricted files for an application may reside in the private section. Files that your application downloads at runtime are also stored in the private section of the cache. There are several utilities for working with assemblies and the cache area. These utilities are covered in the next series of articles (Part 2 -- 3). All assemblies in the global cache must be shared and must contain unique namespaces. The folder names themselves contain part of the assembly's unique identity. The Assembly Cache can be found in your Windows directory in a subfolder called assembly. Check either C:\WINNT\Assembly or C:\Windows\assembly.

This article is the second part of a three part series of articles covering the .Net assemblies. In Part 1, I coved what exactly an assembly is, and what an assembly contains. In this article, Part 2 of the series I will discuss both Private and Shared assemblies and how to create a "Shared Assembly". It is assumed that you are already familiar with creating apps or dll files. I will briefly mention some of the utilities available

for working with assemblies. Part 3 will discuss in more detail than Part 2, the details of the available utilities for manipulating assemblies. Assembly Accessibility There are two types of assemblies when referring to accessibility: Private and Shared. Private: Assemblies are private by default. Private assemblies must accompany all other files in the assembly. This keeps the assembly coherent as one assembled unit. This makes sense because its current compiled application domain can only use a private assembly. Private assemblies do not need to worry about namespace clashes since each compilation and deployment of a private assembly runs within in its own application domain. Shared: To share an assembly such as DLL you've created, you must give the assembly a shared name. You may often see the shared assembly name referred to as a "strong name". Shared assemblies must reside in the Global Assembly Cache discussed in Part 1. A shared assembly must also have a unique namespace. The unique identity is derived through the use of public key cryptography.

Why to create a shared assembly The following are some reasons why you may want to create a shared assembly: Code sharing or code reuse and version control are the more probable reasons. Grouping code according to security permissions is also another reason. The benefits of creating a shared assembly are that through the use of the cryptography keys, you are guaranteed not to experience a namespace clash. Version control prevents someone from trying to add his or her own version of your code. (The smallest unit that can be controlled by versioning is the assembly, and an assembly must be shared in order to use versioning). There are several reasons why you may want to create a shared assembly: Code sharing or code reuse and version control are the more probable reasons. Grouping code according to security permissions is also another reason. The benefits of creating a shared assembly are that through the use of the cryptography keys, you are guaranteed not to experience a namespace clash. Version control prevents someone from trying to add his or her own version of your code. (The smallest unit that can be controlled by versioning is the assembly, and an assembly must be shared in order to use versioning). A shared assembly can consume fewer resources when loading a type that is referenced in multiple application domains. Resources are reduced because instead of loading the type in each application domain, it is loaded only once and then mapped to all other references.

Creating a Private Assembly As mentioned earlier, the default access for an assembly is private. Unless you take measures to create a shared assembly, when you compile your application using the SDK supplied compiler vbc.exe, a private assembly is created with the proper manifest information. This happens via the command line or by building from within Visual Studio .NET. Compiling some code as follows:

vbc HelloWorld.vb produces the application/private assembly HelloWorld.exe Creating a Shared Assembly Creating a shared assembly is a little more involved. Microsoft has supplied all the tools needed to perform this task. The first item we will need is an assembly compiled in the normal way. We will create a module for this called Hello.dll that contains the following code: namespace hello { using System; public class Class1 { public Class1() { } public void SayHello(string name) { Console.WriteLine("Hello " + name); } } } The first tool required is the "Strong Name" utility. Your SDK should contain a file named: sn.exe. Running the Strong Name utility will provide you with a file containing the public and private keys to use. These keys will later be used to give our assembly the guaranteed unique name. From the command line run the following command: Sn -k myKeys.snk

The Strong Name utility will generate a file called myKeys.snk, where the snk extention stands for "strong name key". The -k designates the output file, that we have named myKeys.snk in this example. There are other switches that we will discuss in Part 3. If you did not run the command from your project folder, then copy the file that just created to your projects folder. Signing the Assembly Now we have the keys but we still need to tell our program to use a key. Adding the key to

the assembly is referred to as "signing" the assembly. To do this we need to open a file that is located in your project folder called AssemblyInfo.vb In Visual Studio .NET you can look in the Solution Explorer under the project node. Right-click on the AssemblyInfo file and select Open. If you are not using Visual Studio then any text editor should work. Scroll down to toward the end of the file and look for the following line: [assembly: AssemblyKeyFile("")] Edit the file and place the name of your key file between the quotes in the parentheses. The line in your AssemblyInfo.vb file should now look like this: [assembly: AssemblyKeyFile("myKeys.snk")] We have now told the compiler to use our keys to digitally sign the assembly, thus creating a guaranteed unique namespace. However, you must re-compile the code in order to complete the process. Compile the program with the edited version of the AssemblyInfo.vb file. Important: In order for the assembly to use your private signature (key file), you must recompile your program. Sharing Your Code In order for your code to be shared with other assemblies you need to place your newly signed, shared assembly in the global section of the Assembly Cache. Unfortunately you cannot just copy your code over to the global cache folder. You need to run another command line utility that Microsoft has supplied called Assembly Linker. In your SDK should be a file named AL.exe. The Assembly Linker will create the proper folder in the Global Assembly Cache. This folder's name will contain part of the assembly's unique identity. To run the AL program, go to a command line (make sure the current folder is the same folder your hello.dll file is in) and type in the following command: AL /install:Hello.dll The preceding command can also be shortened to AL /i:Hello.dll. The Assembly Linker program has other uses that I will mention in Part 3 of this article series. Now if you look in your Global Assembly Cache you should see a new folder where your assembly was placed for sharing. My system placed the assembly at: C:\Windows\assembly\global\T2\LGRE\hello.dll

Your system will use something slightly different. Now were ready to test the assembly to see if we can access the SayHello() method. Using the Shared Assembly Now let's create a small program that will call the SayHello() method that resides in our shared assembly. When you compile this program you will need to set a reference to the original shared assembly. Make sure that the reference path points to where the hello.dll file resides and not the current project path. namespace myHello { using System; using hello; public class HelloClass { public HelloClass() { } public static int Main(string[] args) { Class1 speak = new Class1(); speak.SayHello("John"); return 0; } } } After you compile the program you can place the myHello.exe file most anywhere in your system's file path and it will locate the locate the shared assembly hello.dll when you run the application. When you run the myHello.exe application the result will be: Hello John This works because the runtime will check specific search paths starting with the application's base path, and eventually the Assembly Cache. If we had not created the hello.dll as a shared assembly, and then tried to run the application without the hello.dll in the applications base folder, then we would have received an error such as: Exception occurred: System.TypeLoadException: Could not load class "Class1"... Using shared assemblies can allow you to reuse code, maintain a unique namespace, and maintain version This article is the third part of a three part series of articles covering the .Net assemblies. In Part 1, I covered what exactly an assembly is, and what an assembly contains. Part 2 of the series I discussed both

Private and Shared assemblies and how to create a "Shared Assembly". In part 2 I briefly mentioned some of the utilities available for working with assemblies. In this part I will discuss in more detail than Part 2, the available utilities for manipulating assemblies. Assembly Linker Utility The Assembly Linker is a command line utility named AL.exe. Ran in the form of AL sources options. It can be used for installing shared assemblies into the Global Assembly Cache. It can also be used to create a manifest for IL code that does not already contain one. It can be used to add resources to an assembly. Some interesting options that can be used with the utility are: AL moduleName.dll /out: newName.exe /main: methodName

If you have a multi-file assembly, that includes more than one Main method, you can specify to the application domain which type contains the Main method that you want to use as the entry point for your program. AL moduleName.dll use /v: /out: newName /version: major.minor.revision.build or

Adds your specified version number to the manifest. You can verify your version was inserted using the ildasm.exe program. AL moduleName.dll /out: newName /win32icon: iconFileName

Adds an icon file to the assembly so that when Windows Explorer displays your app, the specified icon is shown. Many of the fields that can be added using the AL.exe utility such as Company, copyright, etcetera, can be viewed using the Assembly Cache Viewer/properties. Strong Name Utility The Strong Name utility is a command line utility named Sn.exe. Ran in the form of Sn sources options. It can be used to create strong names or shared names for assemblies. It can be used to create public/private key pairs.

Some useful options that can be used with the utility are..... Sn -k keyFile.snk

This is the same command that we used in Part 2 to create a set of keys. Sn -R assemblyName keyFile.snk

Re-signs a previously signed assembly. Sn -v hello.dll

This verifies that the assembly is a strong named assembly. Assembly 'hello.dll' is valid Assembly Cache Viewer The Assembly Cache Viewer is a Windows Shell extension named Shfusion.dll . This extension is integrated into Windows Explorer when the SDK is installed so that you may view assemblies in the Assembly Cache. It can be used to view properties of assemblies, add assemblies to the cache or even remove assemblies from the cache. Use Explorer to navigate to your assembly directory: C:\Windows\assembly. Right-click on an assembly, and select properties. You will see properties such as version, name trademark, copyright, and others. This method can also be a quick way to verify that fields you set using the Assembly Linker utility are as you expected. To delete an assembly from the cache, right-click on the assembly and select Delete. To add an assembly to the assembly cache, drag and drop the assembly (that must be a shared name assembly) into the Cache. NOTE: Adding an assembly this way does not perform the install as does the AL.exe utility. I used the preceding method to copy and delete assemblies from the cache and it did not create or remove the parent folders of the shared assembly. Global Assembly Cache Utility The Global Assembly Cache Utility performs the same operations on assemblies as the Windows shell extension rescribed above. The Global Assembly Cache Utility is the command line version and is included with the SDK as a file named Gacutil.exe. Syntax and usage is as follows: Gacutil -l

The -l (ell, not number one) option will report the number of shared assemblies in the global cache and will list each shared assembly along with it's version and strong name. Gacutil -i assemblyName

This installs the assembly to the global cache and does create the needed directories just as the AL.exe utility did when we installed the assembly in PART 2 of the series. I tried using the -u option to remove my assembly but this option did not properly work. The Gacutil -u assemblyName, ver=versionNum command ran and said that it successfully removed my assembly, but when I viewed the cache the assembly and it's parent folders were still there. Microsoft Intermediate Language Disassembler The IL Disassembler is a utility named ildasm.exe. It can be used for viewing the internals of an assembly and can also generate a text file that can be edited and then recompiled using the Microsoft Intermediate Language Assembler (ilasm.exe). ildasm This produces a dialog box that allows you to navigate the assemblies internals. The following is a list of the symbols used to identify the parts of your assembly. How to Register and Unregister a DLL or ActiveX controls using Regsvr32.exe 1. 2. Regsvr32.exe is a program that you can use to register and unregister dynamic-link libraries (DLLs) and ActiveX controls (formerly called OLE Custom Controls) in the registry. Regsvr32.exe is installed in the System folder. On a 64-bit version of a Windows operating system, there are two versions of the Regsv32.exe file: - The 64-bit version is %systemroot%\System32\regsvr32.exe. Path: C:\Windows\System32\regsvr32.exe - The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe. Path: C:\Windows\SysWOW64\regsvr32.exe Regsvr32 is the command-line tool that registers DLL files as command components in the registry. Regsvr32 is used for registering a COM based DLL. Regsvr32 generates, registers, and installs a type library into a specified COM+ 1.0 application. To be used with regsvr32, a DLL must export the functions DllRegisterServer and DllUnregisterServer. Regsvr32 will load the library and try to call the DllRegisterServer() from that library. It doesn't care what DllRegisterServer() actually does it just calls that function and checks the returned value. You use it to register COM servers in unmanaged DLLs.

3. 4. 5. 6.

7.

8. 9. 10.

11. 12.

13.

It can't generate a .tlb file. Most often, RegSvr32.exe fails because the LoadLibrary, DllRegisterServer, or DllUnregisterServer function fails. LoadLibrary can fail because: - If the DLL is not in the specified path, or if the specified path is incorrect. - If one of the dependencies of the DLL that you are trying to load is not met; in other words, if a dependent DLL is not present or is not in the specified path. You can use the Depends.exe tool to check whether or not all of the dependencies of your DLL are met. Your DLL must implement DllRegisterServer and DllUnregisterServer, that contain the logic that is necessary to add or delete the required registry entries for the COM component. RegSvr32.exe finds the entry point to these functions, and calls them appropriately. If you use the Microsoft Active Template Library (ATL) Wizard to create the COM DLL, the Wizard generates the necessary code for DllRegisterServer and DllUnregisterServer.

Register a DLL using regsvr32.exe 1. RegSvr32.exe has the following command-line options: Regsvr32 [/u] [/n] [/i[:cmdline]] dllname - /u - Unregister server - /i - Call DllInstall passing it an optional [cmdline]; when used with /u calls dll uninstall - /n - Do not call DllRegisterServer; this option must be used with /i - /s - Silent; display no message boxes (added with Windows XP and Windows Vista) 2. For example, to manually register the Sample.ocx ActiveX control, you would type the following at the command prompt: C:\Regsvr32.exe Sample.ocx NOTE: This command line assumes that Regsvr32.exe and Sample.ocx are both in the root folder of drive C. Unregister a DLL using regsvr32.exe 1. For example, to manually unregister the Sample.ocx ActiveX control, you would type the following at the command prompt: C:\Regsvr32.exe /u Sample.ocx NOTE: This command line assumes that Regsvr32.exe and Sample.ocx are both in the root folder of drive C. Common errors while registering a DLL using regsvr32.exe 1. The command-flag "%1" is not valid. Please review the command usage and try again.

Cause: The user entered an invalid combination of command line switches or arguments when invoking the regsvr32.exe application. 2. This command is only valid if a Microsoft Visual Studio OLE Custom Control project is opened. Cause: Microsoft Visual Studio invoked or ran the regsvr32.exe application but there were not modules included in the command line arguments. 3. To register a module, you must provide a binary name. Cause: Regsvr32.exe was invoked or called with no modules to register located in the command line arguments. 4. The command OleInitialize failed to run. Your computer might be low on memory. Close any open programs and then try again. Cause: The regsvr32.exe tool has to initialize the Microsoft COM library before calling the required COM library functions. It also has to unitialize the library when it shut down. Typically this results when either action has failed. If no cause can be determined then this can sometimes be solved by restarting the computer system. 5. The module "%1" failed to load.\n\n Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files.\n\n%2. Cause: Windows had issues with loading the module identified in the command line. The specific error text will be provided as part of the message. 6. The module "%1" was loaded but the entry-point %2 was not found. \n\n Make sure that "%1" is a valid DLL or OCX file and then try again Cause: The regsvr32.exe application was not able to locate the entry point to the module identified in the command line. This commonly results from improper entrypoint exportation from the module or if the file is not truly a DLL or .OCX file. 7. The module "%1" was loaded but the call to %2 failed with error code %3. \n\n For more information about this problem, search online using the error code as a search term. Cause: When regsvr32.exe invoked the entrypoint in the DLL module an error was thrown. The specific error code will be included with the displayed message. 8. The module "%1" may not compatible with the version of Windows that you're running. Check if the module is compatible with an x86 (32-bit) or x64 (64-bit) version of regsvr32.exe. Cause: Commonly occurs if the 32 bit version of regsvr32.exe is run with a 64 bit version of the DLL.

Assembly is smallest unit of deployment. An assembly consists of one or more files (dlls, exe's, html files etc) and represents a group of resources, type definitions and implementation of those types. An assembly may also contain references to other assemblies. The assembly manifest contains the version information. An assembly is the smallest unit that you use to define the version of an application. The version of an assembly determines the version of the types and the other resources that it contains.

The .Net framework allows the execution of multiple versions of the same assembly on the same machine. The side-by-side execution of assemblies overcomes the problem known as DLL Hell, which is one of the major problems associated with COM applications.

Assemblies are the smallest units to which the .Net framework grants permissions. They provide security boundaries within the .Net framework. When the assembly is loaded into the runtime, the assembly sends the request to the runtime to grant the permission. The permission granted depends on the policy files that are checked by the security engine of the runtime.

Assemblies are a fundamental part of programming with the .net framework. An assembly performs the following functions:

Functions or Features:

It contains the code that a CLR executes.

MSIL code in a portable executable file will not be executed if it doesn't contain the associated assembly manifest.

Each assembly can have only one entry point( that is DllMain, WinMain, Main )

It forms a security boundary. An assembly is a unit at which permissions are requested and granted.

Type Boundary: Every type identity includes the name of the assembly in which its resides.

Reference Scope Boundary: The assembly manifest contains assembly metadata that is used for resolving types and satisfying resources requests.

Version Boundary: The assembly is the smallest versionable unit in the CLR, all types and resources in the same assembly are versioned as a unit.

It forms a deployment unit: When an application starts, only the assemblies that the application initially calls must be present. Other assemblies, such as localization resources or assemblies containing utility classes can be retrieved on demand.

Side-by-Side Execution is supported by assemblies.

Understanding Namespaces:

The .Net Framework class library consists of reusable classes, which are organized in hierarchical namespace. A namespace contains logically and functionally- related classes and divides an assembly into a logical grouping of types. e.g. System.Data namespace contains all the classes that you require to build database applications, and System.IO namespace contains all the classes that you require to perform input and output operations within a program. Multiple assemblies can use the same namespace.

Assemblies can be staic or dynamic. The following is the defination for static and dynamic assemblies.

Static assemblies : Static assemblies can include .Net framework types (interface and classes) as well as resources for the assembly. Static assemblies are stored on disk in PE file.

Dynamic assemblies : The dynamic assemblies can be created using the .Net framework and they are not saved to disk before execution. You can save dynamic assemblies to disk after they have executed.

Assembly Contents

In general, a static assembly consists of four elements:

Assembly Manifest

Type metadata

MSIL code that implements the type.

Set of resources.

Note:-There are several ways to group these elements in assembly. Two ways to group these within a single file or with different set of files.

The elements of an assembly can be contained in several files. These files can be modules of compiled code (.netmodule), resources.

Assembly Manifest:

Every assembly, whether static or dynamic, contains a collection of data that describes how the elements in the assembly relate to each other. Assembly Manifest contains the following information:

Assembly Name: A text string specifying the assembly name.

Version Number: A major, minor, revision and build number. The CLR uses these numbers to enforce version policy.

Culture: Information on the culture or language the assembly supports. The information should be used only to designate an assembly as a satellite

assembly containing culture- or language-specific information.

Strong Name Information: The public key from the publisher if the assembly has been given a strong name.

Type Reference Information: Information used by the runtime to map a type reference to the file that contains its declaration and implementation. This is used for types that are exported from the assembly.

Type Metadata:

The other component of assembly is type metadata. Metadata can be defined as data about the data; this means the metadata contains all the information about the assembly. Metadata defines the contents of the assembly. Metadata contains information such as:

Classes that are there in the assembly.

Interfaces, Events, Indexers that are used in the assembly.

Structs and all the types' information.

MSIL Code

MSIL code is Microsoft intermediate language. The source code is compiled by .net compiler that will convert the source code into the IL code or MSIL code that is intermediate code and then this MSIL code that resides on PE file i.e. portable executable code convert into machine code using JIT with the help of CLR.

Types of Assembly:

There are three types of assembly.

Private Assembly:- These are those assemblies, which are used by single application and are stored in the application directory or a sub-directory beneath. Here the scope of this assembly is limited to the application itself and this assembly can't be shared by multiple assemblies. If you want to use this private assembly, you have to either copy this assembly or paste under the bin folder or you can create the reference of this assembly using the Add reference dialog box and use this assembly. The limitation with the private assembly is that it can't be accessed by two application.

Shared Assembly:- A shared assembly can be used by multiple assemblies. A shared assembly is normally stored in GAC (Global Assembly Cache), which is a repository of assemblies maintained by the .Net runtime. Shared assemblies are usually libraries of code which many applications will find useful e.g. crystal report classes which will be used by all application for reports.

Satellite Assembly:- In multi lingual application in .Net to support multilingual functionality you can have modules which are customized for locations. These assemblies are called as satellite assemblies. Here in these assemblies we can distribute these assemblies separately than the core modules. GAC An assembly that is shared by multiple applications is called a global assembly and is installed in the global assembly cache (GAC). The GAC is a machine wide cache that contains the assemblies that are shared by multiple applications. GAC is used where shared .Net assembly reside. GAC is used in the following situations:

If the application has to be shared among several applications.

If the assembly has some special security requirements like only administrator can remove the assembly. If the assembly is private then simple delete can remove the assembly.

Note:- Registering .Net assembly in GAC can lead to the old problem of DLL Hell. Where COM version was stored in central registry, so GAC should be used when absolutely necessary.

DLL Hell: " DLL Hell " refers to the set of problems caused when multiple applications attempt to share a common component like a dynamic link library (DLL) or a Component Object Model (COM) class. In the most typical case, one application will install a new version of the shared component that is not backward compatible with the version already on the machine. Although the application that has just been installed works well, existing applications that depended on a previous version of the shared component might no longer work. Sometimes, the previous version not able to produce the desired results.

The reason for these issues is that version information about the different components of an application is not recorded or enforced by the system. Also, changes made to the system on behalf of one application will typically affect all applications on the machine.

The solution to this problem is GAC. This Cache is a repository for all the .Net components that are shared globally on a particular machine. When a .Net component is installed onto the machine, the Global Assembly Cache looks at its version, its public key, and its language information and creates a strong name for the component. The component is then registered in the

repository and indexed by its strong name, so there is no confusion between different versions of the same component, or DLL.

.Net Framework introduced something called side- by-side execution. Side by side is the ability to install and run multiple versions of the same component on the machine concurrently at the same time without interfering with each other. With components that support side-by-side, authors aren't necessarily tied to maintaining strict backward compatibility because different applications are free to use different versions of a shared component.

Strong Name in .Net Assembly

Strong Name is similar to GUID (It is supposed to be unique in space and time). In COM components. Strong name is only needed when we need to deploy assembly in GAC. Strong names help GAC to differentiate between two versions. Strong names use public key cryptography (PKC) to ensure that no one can spoof it. PKC use public key and private key concept. Following are the step to generate a strong name and sign an assembly:

Step1: Go to Microsoft Visual Studio 2005 >>Visual Studio Tool>> Visual Studio Command prompt. This wills popup the command prompt for you.

Step2: After the command prompt run the strong tool from there Sn.exe k c:\test.snk Here k: the key specifies that we want to generate the key. test.snk: This file contains the key that is generated by the sn.exe tool

Step3: This will create the file at the following location. When you open the file that has been generated by the strong name tool. This is not a readable format because of security reasons.

Step4: Once the strong name key/value pair is generated using the strong name utility. We need to assign it to the project.

Step5: This will assign the strong name to this project. Then compile the project again to reflect the changes. The Strong Name is needed to insert the assembly into the GAC.

Add/Remove an assembly from GAC:

Here you can use other .Net tool to put the assembly in the GAC i.e. gacutil.exe

Go to Microsoft Visual Studio 2005 >>Visual Studio Tool>> Visual Studio Command prompt >> gacutil.exe i (assembly_name) where assembly_name is the DLL name of the project. To remove the assembly run this command. gacutil.exe u (assembly_name)