Assemblies In .NET Application

Topics that I am going to cover in this article

• What are Assemblies?
• Types of Assemblies.
• Managing Assemblies in Global Assembly Cache.
• Generating a Public Key.
• Creating a Shared Assembly.
• Versioning of Assembly.

Let’s Start

What is assembly in .NET?

Assemblies are the core building blocks of .NET applications. In simple terms, assembly is the .dll or .exe file that is created while building any .NET application. You can find many definitions for assembly over the internet also. In my point of view, assembly is the building block that is created after a successful build operation of your application. After the compilation of each project, a .exe or .dll file is generated, known as Assembly. The name of an assembly file is the same as the project name. The assembly of a project is present under the bin\Debug folder of that project folder. After the successful build of each project, an assembly is generated inside that folder. We can use assembly files by our requirement we may directly take the assembly file and install it into the client machine if it is .exe type or we can consume the file in another project if the assembly is dll type. Class Library and Windows Forms Control Library projects generate a .dll assembly whereas Windows Forms Applications, Console Applications, WPF Applications, and Windows Services projects generate a .exe assembly. .Exe type assembly is run by their own as well as they provide support to others in their execution process so these assemblies are known as an in-process component whereas .dll type assembly is called as out process component because they are only developed for the purpose to consume inside .exe type of application.

Note. Every application is a blend of both .dll and .exe assemblies combined to give better efficiency.

Types of Assembly

In .NET, we have two types of assemblies

1. Private Assembly
2. Shared Assembly

Private Assembly When we build any project we find a corresponding assembly inside the bin/Debug folder; so by default, this assembly is a private type. It's private because when we add that assembly reference to another project then a copy of that assembly is created inside that project. The below figure is an example of Private assembly.

Creating an assembly to test if it is private, by default, Start a new project inside Visual Studio of type Class Library and name it as “PAssembly”, we take class library because we can consume this project dll file inside another project. Here I am using VS2012 for my project creation.

in this project, you find a file called Class1.cs. Now, write the following code under the class.

public string TestHello() {
    return "Hello from private assembly";
}

Now, compile the project by opening the Solution Explorer, right-clicking on the project, and selecting “Build” or pressing "Ctrl+shift+B" which will build + compile your project and generate an assembly with the name PAssembly.dll.

Note. We can find the path for our assembly in the output window.

Testing the assembly we have created

Open a new project of type Windows, name it “TestPAssembly”, place a button on the Form, and set its text as “Call TestHello method of Class1 in PAssembly.dll”. Now, add the reference of PAssembly.dll from its physical location and write the following code under the click of a button.

PAssembly.Class1 obj = new PAssembly.Class1();
MessageBox.Show(obj.TestHello());

Run the project to test it. Then, go and verify under the bin/debug folder of the current project where we can find a copy of PAssembly.dll as it is a private assembly.

Note. The advantage of a private assembly is faster execution because it is available in the local folder, whereas its drawback is that multiple copies get created when multiple projects add the reference to consuming it.

Shared assemblies

As we saw above while consuming private assembly it always created a copy of that file inside the project bin/debug folder; so if we want to use that assembly in several applications then we are required to put that assembly inside a shared folder. That shared folder in .Net is called a Global Assembly Cache folder. We can add several assemblies inside that folder and consume that assembly for any project.

Note. Before consuming we need to add the assembly inside the GAC folder; due to GAC being present under the window directory so reading, writing, and deleting can only be available when we permit that folder.

Managing assemblies in the global assembly cache

To manage assemblies in GAC, like install, uninstall, and view, we are provided with a tool known as Gacutil.exe (Global Assembly Cache Tool). This tool is automatically installed with Visual. To run the tool, use the Visual Studio Command Prompt.

Where is the VS command prompt?

Go to the Start menu and click on the Visual Studio folder - Inside this, you find the VS Command prompt.

These utilities enable you to run the tool easily, without navigating to the installation folder. To use Global Assembly Cache on your computer, On the Taskbar, click Start --> All Programs --> Visual Studio. Click Visual Studio Tools and then click Visual Studio Command Prompt and type the following.

gacutil [/i | /u | /l] <assembly name>
/i: Install
/u: Un-install
/l: List

Note. Assemblies deployed in the GAC must have a strong name. When an assembly is added to the global assembly cache, integrity checks are performed on all files that make up the assembly.

What a strong name is?

When an assembly is created by using Name + Version + Public Key then it's called a strong name

1. Name: Every assembly has its name which comes by default when you build your project.
2. Version: All software comes with a Version number; without a version number we can not identify it, so when we create assembly it comes with a default version number called "1.0.0.0"
3. Public Key: A public key is a key through which GAC can identify the assembly. As we know GAC contains all the assembly so to identify uniquely GAC uses this public key.

You can ensure that a name is globally unique by signing an assembly with a strong name. In particular, strong names satisfy the following requirements, Strong names guarantee the name's uniqueness by relying on unique key pairs. No one can generate the same assembly name that you can. Strong names protect the version lineage of an assembly. A strong name can ensure that no one can produce a subsequent version of your assembly. Users can be sure that a version of the assembly they are loading comes from the same publisher who created the version the application was built with. Strong names provide a strong integrity check. Passing the .NET Framework security checks guarantees that the contents of the assembly have not been changed since it was built.

Generating a public key

To sign an assembly with a strong name, you must have a public key pair. This public cryptographic key pair is used during compilation, to create a strong-named assembly. You can create a key pair using the Strong Name tool (Sn.exe) from the Visual Studio command prompt, like the following.

sn -k <file name>
E.g.: sn -k Key.snk

Note. The above statement generates a key value and writes it into the file “Key.snk”. Key pair files usually have .snk extension

Creating a shared assembly

Step 1. Generate a public key. Open the VS command prompt, go into your folder, and generate a public key as follows: <drive>:\<folder> sn -k key.snk.

Now, my key.snk is successfully created inside Drive ‘E’.

Step 2. Develop a new project and associate the key file to it before compilation, so that the assembly which is generated will be Strong Named. To do this, open a new project of type Class Library, name it “SAssembly”, and write the following code under the class Class1.

public string TestHello() {
    return "Hello from shared assembly 1.0.0.0";
}

To available key files within the project, we need to follow the below steps.

Step 1. Open the project property window.

Step 2. Click on the Sign in the tab then you see a checkbox for Sign the assembly; you need to check there and then select your key from the browse option as below.

Now, browse your folder and choose the key.snk file.

Click OK. Then, the key shows you inside the Visual Studio.

Now, build the project; and it’s ready with the dll with key inside your Bin\debug folder.

Step 3. Install the assembly into GAC by using the “Global Assembly Cache Tool”.

To install the assembly, open Visual Studio Command Prompt, go to the location where SAssembly.dll is present, and write the following:

<drive>:\<folder\SAssembly\SAssembly\bin\Debug> gacutil -i SAssembly.dll

Again, open this in Admin mode and run the above command.

Step 4. Testing the Shared Assembly.

Open a new project of type Windows, name it “TestSAssembly”, place a button on the form, and set its text as “Call SayHello method of Class1 in SAssembly.dll 1.0.0.0”.

Now, add a reference of SAssembly.dll from its physical location and write the following code under the click of a button.

SAssembly.Class1 obj = new SAssembly.Class1();
MessageBox.Show(obj.TestHello());

Run the project, test it, and verify under the bin/debug folder of the current project where we will not find the only copy of SAssembly.dll as it is a shared assembly.

Check inside the project Bin/debug folder.

Versioning assemblies

As I said above every assembly has a version number; so to define the version number we have some protocol through which we can give the version name with their different build. So all this information can be found inside the AssemblyInfo.cs file inside each project.

The AssemblyInfo.cs contains the following information.

• Major Version
• Minor Version
• Build Number
• Revision

This is all about .NET Assembly and its uses. So, I think I have covered all the topics successfully.