Assembly and Module

By: Saurabh Nandu - Friday, May 4, 2001 Add Comment

Introduction The current Windows Programming model is a Hell for the developer as well as for the end-user. Just think if you have written an application. In order to install this application on the clients computer, first you have to copy the application files to a particular directory and then create several registry entries in clients registry. Some special shared libraries have to be copied to the Windows or System directory. If the client wants to uninstall your application he has to see to it that all the files are deleted, registry entries are removed and shared libraries are appropriately dealt with. But this process is not fool-proof, very often clients come across dreaded errors because some unwanted changes have been made to the registry. Users who are used to installing multiple software's might have definitely experienced that uninstalling unwanted applications is not enough! Even applications with good uninstallers leave behind many stranded libraries and registry entries. Such is the dreaded situation that there are companies like Norton that are actually selling applications like Norton Clean Sweep which help the end user find and remove stray registry entries and libraries left behind by uninstalled programs! Microsoft has finally recognized the cry of developers and totally done away with the use of registry on the .NET Platform. On the .NET Platform, if you want to install an application, all you have to do is XCopy all the program files to a directory on the clients computer. Similarly, if you want to uninstall the application just delete the directory containing the application and your application is uninstalled, no more stray registry entries or libraries! One more obvious but silent reason for Microsoft removing the dependence on the registry is the fact that Microsoft is planning to make applications on the .NET Platform, Platform independent and the Windows Registry is not supported on any other platform. Great, so how does the .NET Platform achieve freedom from registry? Metadata stored within the Assembly, is Microsoft's solution to the registry problem. On the .NET Platform programs are compiled into .NET PE (Portable Executable) files. The header section of every .NET PE file contains a special new section for Metadata (This means Metadata for every PE files is contained within the PE file itself thus abolishing the need for any separate registry entries). Metadata is nothing but a description of every namespace, class, method, property etc. contained within the PE file. Through Metadata you can discover all the classes and their members contained within the PE file. I shall give you more information on Metadata in some other article. In this article I will describe the basic concept of Assemblies and Modules on the .NET Platform without going into much technicality. Assembly On the .NET Platform applications are divided into Assemblies and Modules. An Assembly contains the information required by the .NET runtime to find, load and execute applications on the .NET Platform. Let's take an analogy, when you are building a big application, the general practice is to build all the classes and methods used very often into a single executable (*.exe) file and rest of the required classes are put into Library Dll's. Similarly, on the .NET Platform, the important, basic and regularly used classes form a part of the main file which acts as an assembly file, while the rarely used classes can be put into modules. The logic behind the concept of assemblies and modules lies the fact that with the help of these you can separate out units of code based on their usage and importance, physically (in different files) and logically (in Assemblies and Modules). For example: You can build an application that works off the Internet from your browser. First the application file containing the Assembly gets downloaded on the client side. This assembly contains only the generally used classes, if client requests a feature which is not very often used, a separate module gets downloaded on the client side which contains the code for that remote feature. This way the size of the initial file (assembly) downloaded is very small and as and when demanded additional files (modules) can be downloaded. Hence we can say an assembly can span across multiple files i.e. assemblies can be made from multiple modules. But then there are some serious differences between Assemblies and Modules that need to be pointed out. Firstly it is not mandatory to break-up your application into assembly and modules, but your application should have at least one assembly.  Secondly, assemblies can be stored in to either an Executable (.exe) or a Library (.dll). Lastly, assemblies can contain MSIL code along with other resources like gif, jpegs, HTML Pages, localization strings etc. Contents of an Assembly: 1)Assembly Manifest 2)Assembly Name 3)Version Information 4)Types 5)Locale 6)Cryptographic Hash 7)Security Permissions Assembly Manifest - An Assembly Manifest is nothing but some extra tables in the Metadata section of the PE file which contains the assembly's identity, culture, files, publicly exported types, and list all of the files (modules etc) that comprise the assembly. It also contains link to other referenced assemblies on which the assembly is dependent. This is the main difference between an assembly and a module. An assembly contains an assembly manifest while a module does not contain an assembly manifest. One point to be noted here is that both assemblies and modules contain Metadata which describes them. It is the self-describing assembly manifest which gives applications on the .NET Platform independence from the registry. In layman's terms say if you have an application comprising of an assembly named Assem.exe and a module named Mod.dll. Then the assembly manifest stored within the PE Assem.exe will not only contain metadata about the classes, methods etc. contained within the Assem.exe file but it will also contain references to the classes, methods etc, exported in the Mod.dll file. While the module Mod.dll will only contain metadata describing itself. You can store the assembly manifest within the executables or libraries created with the /t:exe, /t:winexe and /t:library switches of the C# compiler. Or you can create a separate PE file which will just contain the assembly manifest. Modules Modules are also PE files (always with the extension .netmodule) which contain Metadata but they do not contain the assembly manifest. And hence in order to use a module, you have to create a PE file with the necessary assembly manifest. In C#, you can create a module using the /t:module compiler switch. There are a few ways to incorporate a module into an Assembly. You can either use /addmodule switch to add module/s to your assembly, or you can directly use the /t:exe, /t:winexe and /t:library switches to convert the module into an assembly. Please remember that the compiler will generate a error you try to add a module to your assembly using the /r (/reference) compiler switch. (Note: Some parts of this article have been taken from Jeffrey Richter's articles on MSDN and from Chris J. Rausch's article on C# Corner.)

Assembly and Module

Comments