A2Z Dotnet – Gain & Share Dotnet Knowledge

.NET Foundations - .NET assembly structure

Every once in a while, I've been asked by a non .NET developer (VB6, C++ etc) to explain "how .NET works, how
GC works, why boxing is bad etc". I'm usually trying to find a link and save some of my time but for some of the
subjects i am not able to find the appropriate ones (either they are too wide or too short and partial in presenting
answers). Therefore, to save me some time in a future repeating the same whiteboard session I decided to make
a couple of blog post explaining .NET foundations. That + I got bored from all this architecture posts :)

Today's post would try to give answer on first half of the "how .NET works" question by trying to explain NET
assembly structure only. Next post would then cover the second part of that answer explaining the NET assembly
execution model.

General level explanation

.NET framework gives to developers freedom of choosing the language they would like to use in doing .NET
programming (C#, VB, C++/CLI ...). It even enables using multiple languages in the same project where the code
developed in different languages cooperate seamlessly. That is possible due to the fact that .NET framework
operates only with the intermediate language (IL) code. IL code is created during the compile time by language
compilers which translate high level code (c#, vb..) concepts to a combination of language agnostic IL code and
its metadata. That IL code together with that metadata and headers makes a unit called managed module.

One or more managed modules and zero or more resource files are linked by language compiler or assembly
linker to a managed assembly, which we see as .net DLL file. Every assembly contains also embedded manifest
file which describes structure of the assembly types member definition, structure of external assembly member
references etc

This diagram and general level explanation are roughly sufficient for L100 explanation, but my personal
preference is that always complement the big picture approximated explanation with some concrete
implementation details so I'll do that here to by explaining in more details structure of managed module . I'll try to
minimize talking and maximize illustrations and pictures so it would be shorter, more reader friendly while still
having some weight.

C# code file
In this post, I would use very simple example where we would have a single class console application which
would write two lines to console.
Created by Satya Puvvada
A2Z Dotnet – Gain & Share Dotnet Knowledge
Something like this:

view plaincopy to clipboardprint?

1. namespace CSharp_ILCode
2. {
3. class Program
4. {
5. static void Main(string[] args)
6. {
7. System.Console.WriteLine("Hello world!");
8. Hello2();
9. }
10.
11. static void Hello2()
12. {
13. System.Console.WriteLine("Hello world 2x!");
14. }
15. }
16. }

As we can see on a diagram above, that code would during compile time be "translated" to IL code with
appropriate metadata definition and that would all then become one managed module and through that NET
assembly

Managed module
Any managed module, regardless of the fact from which code was created consist of next four big parts:

1. PE32 header
2. CLR header
3. Metadata
4. IL code

PE header
Every managed module contains the standard windows PE execute header like the non managed - native
application contain too. The only difference in case of managed code is in the fact that bulk of PE header
information is just ignored, while in case of native code that PE header information contain information about the
native CPU code.

To get some information about PE header, in Visual studio command prompt, you have to execute next command

dumpbin /all assembly_name > result.txt

Created by Satya Puvvada