Managed Modules and Assemblies
It is hard to find concise blog post these days as people like talking too much some times :) so I will try to give your concise explanation about these two, Managed Modules and Managed Assemblies.
1. Managed Modules are compiled code containers which means they contain IL code and along with PE32 header,CLR Header, Metadata. CLR ignores PE32 headers though. They are not usable by themselves so they need to be a part of an Assembly in order to be useful in other applications. A netmodule can not be deployed alone. It has to be linked into an assembly. You can use AL.exe in order to link may managed modules in one assembly. C# compiler only compiled one .net module in one assembly which is called single file assembly.
About Managed Modules, I’ve found this article really nice so I would like to share some excerpt from it:
A managed module consists of two very important sections: Metadata: describes the layout of classes, members, attributes, etc. Managed code: CIL methods, global data, etc. (This is optional.)
The astute reader will notice that I have left out two other bits of information that also form a managed module: portable executable (PE) header (Windows. Informs Windows which version of the OS it needs to run, and other things like whether or not it uses a command line interface (CUI), or graphical user interface (GUI), among other things); and the CLR header (this determines which version of the CLR should be loaded into the process). In this article we will ignore the PE and CLR headers and concentrate on the metadata and managed code sections of the managed module.
2. First understand what assembly means in literal manner : ”The process of building something by putting all its parts together” or a “meeting of people who represent different parts of a large organization” (Macmillan). I strongly recommend you to understand the literal meaning before diving into what it means in .NET. So we know that it is something composed of many different parts coming together. Good news! It is something similar to what we use them for within .NET.
Please check this diagram first:
Assemblies contain Assembly Manifest which is something managed modules don’t have. Assemblies are containers which contain managed modules, resource files such as png files etc.
But most of the time, assemblies are composed of only one Managed Module and nothing else. Visual Studio is only capable of putting one managed module in one assembly and resource files if requested specifically.
If you want to add more managed modules in one assembly, then you need to use command prompt and /addmodule flag.
Assembly Manifest is an important thing we should know, it contains all these data defined here.
There is single file assemblies as well as multi-file assemblies:
and multi-file assemblies:
And I am taking this description from MSDN:
In the illustration above, the developer of a hypothetical application has chosen to separate some utility code into a different module and to keep a large resource file (in this case a .bmp image) in its original file. The .NET Framework downloads a file only when it is referenced; keeping infrequently referenced code in a separate file from the application optimizes code download.
I hope it is helpful to you, you can see my actual note here on my Evernote page.
As a summary,
Don’t bother yourself with managed modules since most of the time, you won’t use it. Understand how assemblies work but of course you need little info about the things which makes up assemblies. Assemblies are used most of the time in our daily lives as they are being used by CL R or Mono Run Time. So when you share you code, you share the assembly file Visual Studio created for you.