Introduction
It is pretty common for developers to be trending towards the .NET technology, since the tech is pretty much in vogue these days. And I am pretty sure you must have come across several posts that highly focus on the .NET technology, so we won’t be discussing all the same. As the title suggests, here you will be learning about assemblies in the .NET technology. I mean if you are using the .NET technology, I am sure you are more likely to encounter assemblies. So it is very important to have a better understanding of these assemblies so that you can develop as well as deploy amazing .NET applications.
Get ready to explore everything regarding assemblies, what they are, what role they play in the success of any .NET development project, how to successfully create as well as manage, and what are several security connections are.
What is a .NET Assembly?
A .NET assembly is a fundamental unit which is supposed to be deployed within the .NET Framework to make app development process a smoother and seamless one. So, technically speaking, assembly is a compiled code library which features executable code for developing a successful application. Assembly is the smallest deployable unit, and do you know what is the best part here? It can be reused across multiple applications.
So is Assembly private or shared? Well, I say it can be included among both categories, for example, private assemblies are used by a single application and can be successfully stored within the application’s directory. Whereas shared assemblies, on the other hand, mean it is possible to reuse the code for a wide range of applications and can be successfully stored in the Global Assembly Cache (GAC). For those who don’t know what GAC is, it is a central repository considered for shared assemblies, enabling things to be seamlessly accessed and managed by a wide range of applications.
An assembly is a rare collection of different types as well as resources which are developed to work together. Basically, there is one thing common among all these: they usually intend to form a logical unit of functionality. Some of the core aspects assemblies feature are:
- Versioning information
- Metadata
- Manifestation
Assemblies can be static or dynamic. Static members are developed at compile time as well as contain all the relevant information used for the CLR to execute the code. At the same time, it is possible to create the dynamic ones, especially during the runtime, and do you know what is the best part here? It is possible to generate code while you are at it. So if you are facing some common scenarios, such as plugin architectures or code generation tools, assemblies can be quite a plus point here.
The .NET assembly is a standard component developed by Microsoft. NET assemblies, which might or might not be executable; however, chances are pretty high it might seem to be an executable (.exe) file or a dynamic link library (DLL) file. Now all the assemblies comprising of types, versioning information for the type, metadata, and manifest.
Types of .NET assembly
Now, .NET tech usually supports three kinds of assemblies:
Private Assembly
Private assembly usually requires copying on a separate basis within all application folders, especially where the assembly functions need to be used: this doesn’t require any copying; in short, you won’t be able to access private assembly features as well as power. This assembly means every time you have one, it is possible to exclusively copy within the BIN folder of each application folder.
Example:
// MyLibrary.cs
namespace MyLibrary;
public class Helper
{
public static string Greet(string name) => $"Hello, {name}";
}
Console App (uses private assembly)
using System;
using MyLibrary;
class Program
{
static void Main()
{
Console.WriteLine(Helper.Greet("World"));
}
}
Shared Assembly
The public assembly is not required to be copied on a separate basis within different application folders. No wonder public assembly is also known as shared assembly. Here, only one copy is required in the system level. And what makes shared assembly worth considering here is? You no longer need to copy the assembly. Usually, it is advisable for a public assembly to be installed in the GAC.
Shared assemblies, often known as strong-named assemblies, are copied within a single location; this is possible using the global assembly cache.
Let’s say you are calling assemblies, but the key is that you need it to be done within the same application, then simply the same copy of the shared assembly will be used. All this will be done from the same, or should I say original, location.
This is the reason why it is not possible to copy shared assemblies into the private folders. Now each shared assembly comprises of certain aspects such as face name, version, public key token, and culture information.
So in case if you want to mix two different assemblies even though it comprises of the same name, the public key token and version information doesn’t really allow it.
Example
namespace SharedLib;
public class Tools
{
public static string Hello() => "Hello from Shared Assembly";
}
Give it a strong name when compiling (so it can go to GAC):
sn -k SharedKey.snk
Add in project:
<PropertyGroup>
<SignAssembly>true</SignAssembly>
<AssemblyOriginatorKeyFile>SharedKey.snk</AssemblyOriginatorKeyFile>
</PropertyGroup>
App Using Shared Assembly
using System;
using SharedLib;
class Program
{
static void Main() => Console.WriteLine(Tools.Hello());
}
Satellite Assembly
Last but certainly not least, satellite assemblies are pretty popular among the three. These types usually allow quick deployment of language and culture-specific resources for any and every kind of application.
Example:
Step 1: Create Resource Files
Strings.resx (default, English)
Greeting = Hello
Strings.fr.resx (French)
Greeting = Bonjour
Step 2: Console App (Main Assembly)
using System;
using System.Resources;
using System.Reflection;
using System.Globalization;
class Program
{
static void Main()
{
var rm = new ResourceManager("Strings", Assembly.GetExecutingAssembly());
Console.WriteLine(rm.GetString("Greeting", new CultureInfo("en")));
Console.WriteLine(rm.GetString("Greeting", new CultureInfo("fr")));
}
}
Step 3: Build → Creates Satellite Assemblies
When compiled, .NET generates:
en\MyApp.resources.dll
fr\MyApp.resources.dll
These are the satellite assemblies for localization.
Some of the core assembly aspects to consider:
- Assemblies are highly self-explanatory; this is a given. So don’t worry about the information; everything is well kept.
- Each move of version dependencies are taken care of.
- Side-by-side loading of assemblies
- In fact, if you want to install an assembly, it is extremely easy. Imagine you are copying a file; it is as simple as that!
- Assemblies might be private or open to the public.
How to Create an Assembly in .NET?
Let's see a single-file example that shows how to inspect the current assembly at runtime:
using System;
using System.Reflection;
class Program
{
static void Main()
{
Assembly asm = Assembly.GetExecutingAssembly();
Console.WriteLine($"Assembly Full Name: {asm.FullName}");
Console.WriteLine($"Location: {asm.Location}");
}
}
Output
Assembly Full Name: MyApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Location: C:\Projects\MyApp\bin\Debug\net8.0\MyApp.dll
Conclusion
Assemblies have been an exceptional part here. Understanding assemblies is pretty basic and the most fundamental. So if you want your app development project to succeed, .NET. Assemblies is a must! It offers an unusual way to distribute and reuse .NET code easily, and one shouldn’t forget, they are extremely important of the framework. Once you have a better understanding of what these assemblies are, how they work, nothing can stop you from creating a secure, maintainable, and easy-to-deploy .NET applications.
I hope you did find the following post worth taking into account. In case, if you have any doubts or queries, feel free to mention them in the comment section below.
Top comments (0)