Hi there! š
Today Iād like to talk about one of the basic ingredients of CLR (and .NET) - the Assemblies. As usual, the infographic goes first, followed by more detailed explanaten below.
I hope that was understandable :)
As you can see - at itās most fundamental level, assemblies are a way of packaging and distributing code. I say āat most fundamental levelā because thereās a lot more going on there, but weāll cover that when the time comes. For now, you can think of them as archives that pack one or more files inside; itās like a .tar, in a way.
One thing you can find inside the assembly, aside from the actual code itself, is Assembly Manifest. And if you stop and think about it, you soon realize that if you have one giant blob of ones and zeroes, and those ones and zeros belong to different files - how do you know what is what? And how do you even know if the assembly is safe to use? Or who created it? Or what the version is? Too many question that beg for an answer. And the answer is simple - Manifest.
Iāll expand lot more on Manifest and whatās inside as part of the next article, but for now just keep in mind that itās like an Identity Card for your assembly. It provides info on WHO created it, WHICH version of the assembly is it, WHAT are the external dependencies that assembly has and what are the files that are INSIDE the assembly. Thatās about it in a nutshell.
Let me show you how to look into your assemblies. Because talking is cool, but seeing it in action makes all the difference in the world. First and foremost, locate your ILDASM.exe (the MS IL Dissasembler). It comes with .NET installation so you should have it somewhere around.
Letās look into the assembly that gets produced as a result of this simple code:
using System;
namespace CsharpDllLibrary1
{
public class Class1
{
private readonly Int32 x;
public Class1(int x)
{
this.x = x;
}
public int GetOne()
{
return 1;
}
}
}
ildasm.exe CsharpDllLibrary1.dll
Thatās cool, right? As you can see - thereās a Manifest, and then thereās my library namespace with a single class inside. Cool!
If you open the Manifest, youāll see something like this:
That's a lot to digest if youāve never encountered it. But what you see in the Manifest is basically the Table of Contents (i.e. whatās inside) plus the Identity Information (which is missing btw but more about it later on).
And if we sneak peak into GetOne() method, you will see something like this:
So in a nutshell, whatās inside the assembly is Manifest, CLR code and optional resources (which Iāll leave for some other time). Iād actually encourage you to locate ILDASM.exe on your computer, find a DLL (or EXE) that was built using some .NET language, and explore whatās inside. You will learn the most by actually doing it.
Another thing thatās interesting to mention is - how does Windows know whether the EXE or DLL contains native code? And the answer lies in - based on the header information. To be valid, EXEs and DLLs have to conform to the Portable Executable (PE) format (and Iāll write more about it as well!) and what CLR does is that it stores info inside that header that the code that follows should be run through the CLR. But again, donāt sweat over it, Iāll cover this in a separate article.
Finally, in the graphic above, I made honorable mention of Global Assembly Cache (GAC). Thatās a very fancy name for a folder that holds commonly shared DLLs (e.g. .NET frameworkās DLLs). GAC is one of the folders where CLR runtime looks for assemblies if they canāt be located in your programās local folder. But thereās a trick to it - for assembly to be elligible to be inside GAC folder, it has to be Strong-named. Strong-named is yet another fancy word for a very simple thing - digitally signed file, whose identity you can verify.
If youāre not familiar with digital signing of content, well, itās really a cool way of claiming ownership of stuff using Private/Public keys. Owner of assembly āsignsā the file (think of it as placing a seal on it) with their Private key, and they provide a (public) key which can only break the seal signed with ownerās private key. It can be a bit mind-boggling but for now just think of it as a very simple & efficient way to confirm ownership of the assembly.
And that would be all I had to share for today! If you enjoyed this content, do consider subscribing. In the next few articles I will talk more about Manifest and Strong-named assemblies before moving on to discuss the Memory Management features of CLR.
Thanks for reading!
Other articles in this series: