----------------------------------------------------------- New Message on BDOTNET
----------------------------------------------------------- From: SitaramanM Message 6 in Discussion Hi This is one of the topics which cause a lot of confusion, thanx to the so many articles which seem to mix-up the two. Unfortunately the MSDN also does not clearly specify the difference. To understand the exact difference ill go thru certain terminologies and then answer your query Managed Module : Whenever you compile your code, the compiler produces a Managed Module(not the same as Assemblies, neither the same as IL). A Managed Module is a standard Windows Portable Executable(PE) format file, but requires the CLR to execute the code contained in it. The Managed Module itself consistes of 4 things, PE Header, CLR Header, MetaData, IL Code PE Header : The standard PE Header is similar to to the COFF(Common Object File Format )header. Contains the info as to whether the file is a CUI or GUI or a DLL. For any module, that contains pure IL Code the majority info stored in this header is ignored. If your module also has native CPU instructions, then this header contains info about the native CPU Code CLR Header ; Contains info like, the version of the CLR Required, MethodDef metadata token to the module's entry point method, resources, strong name etc... MetaData : Every Managed Module contains Metadata Tables(NOTE this point very carefully). These tables can be of three types mainly, a) Definition Metadata Tables, that describe the types and members defined in the source code b) Reference Metadata Tables that describe the types and members referenced by your source code c) Manifest Metadata Tables which alow the developer to provide a level of redirection for consumers of the assembly and allow you to partition any given Assembly. How is the Metadata used : Metadata is used in the .Net environment by various entities a) There is no more any need for header/library files at the time of compiling as all the information about the types/members referenced in the IL Code, as the information about the same is contained as metadata in the file that contains the IL itself. Compilers can read metadata directly from the managed modules b) The intellisense of VS.Net parses the metadata tables to tell you the methods thata type offers and the parameters that it accepts c) The serialization of an object's field and the deserialization of the same on a remote machine , uses metadata extensively d) The GC, tracking the lifetime of an object and collecting it at regular intervals, also used metadata. For example when an object X has other objects referenced inside and X is to be collected,then the GC needs to know all the objects that X referred to. As the metadata contains the type of objects that Object X refers to, this information is used by the GC IL Code : This is the code as the compiler compiled it from source code. This intermediate step ensures that the code is nuetral in terms of OS platform and CPU and later the CLR will compile it(thru the JITter) into CPU specific instructions So note that Metadata is nothing but a set of tables and these tables will be present in every Managed Module. Now lets take a look at Assemblies Single-File Assembly : The interesting point here is that a Managed Module is not the same as an Assembly. Right!!! In a scenario, where i have a Single File Assembly, then i have one Windows PE file , this itself is a Managed Module and is also the Assembly. So for projects where there is only one managed module and no resource files, lets say, the assembly and the managed module are one and the same entity. The default compiler switches compile the source code, produce a managed module and then link it to form an Single File-Assembly Multi-File Assemblies : It is also possible that i might want to partition my Assembly into multiple modules. lets say, i want the code to be in two modules(MainApp.cs, AddlSource1.cs, Resource1.cs, Resource2.cs), the resources in two different modules etc. In that case you would compile the modules using a separate set of switches like 'Compile the individual Modules csc /t:module AddlSource1.cs 'Will result in AddlSource1.netmodule csc /t:module Resource1.cs 'Will result in Resource1.netmodule csc /t:module Resource2.cs 'Will result in Resource2.netmodule Note : Here though the extension is .netmodule, the file is actually a standard DLL PE File only and you could have also given the command as csc / out:AddlSource1.dll /t:module AddlSource1.cs which would have resulted in a AddlSource1.dll Now that we have the modules we can build the MainApp with the command 1) To build MainApp as a Exe: csc /out:MainApp.exe /t:exe /addmodule:AddlSource1.netmodule Resource1.netmodule Resource2.netmodule MainApp.cs (or) 2) To build MainApp as a Dll : csc /out:MainApp.dll /t:library /addmodule:AddlSource1.netmodule Resource1.netmodule Resource2.netmodule MainApp.cs Ill take the compilation command 2) and build a dll. So the csc command will result in a mainapp.dll. Manifest : Here now, i have 4 managed modules(AddlSource1.netmodule , Resource1.netmodule, Resource2.netmodule and MainApp.dll). But All these 4 managed modules atomically known as one assembly. What makes this as the Assembly. It is clear that the MainApp.dll uses the features provided by the other modules. Which means that this file needs to maintain certain metadata tables, which gives information of the other three netmodules that this assembly refers to. These tables are what are known as Manifest metadata tables. The different manifest metadata tables that turn a managed module into an assembly are AssemblyDef tables, FileDef Tables, ManifestResourceDef Tables and the ExportedTypeDefTables. Only One managed module in an entire assembly will contain these Manifest metadata tables. If you prefer, you can also create a managed module which contains nothing but the Manifest Metadata Tables. So to summarise, a) Source Code is compiled to Managed Modules always, by a CLR Targetting compiler b) Managed modules can be broken into four entities PE Header, CLR Header, Metadata Tables and IL Code c) Metadata Tables are present in every managed module(be it exe/library/netmodule etc...) d) Metadata Tables can be of different types/categories , namely Definition Metadata Tables, Reference Metadata Tables, Manifest metadata Tables e) Manifest is one of the types of Metadata Tables f) In a single file assembly, there is one singleWindows PE File(exe/dll). This File = Managed Module = Assembly This file contains the Metadata tablesand as there is only one file, the manifest is also present in this file only g) In a MultiFile Assembly, the Assembly is partitioned into multiple managed modules h) All the Managed Modules contain Metadata Tables j) However, Only one managed module will also contain the Manifest as part of the Metadata Tables k) This Manifest Metadata Table will contain information of the other managed Module which the Assembly needs at runtime The best resource for such information is the "Applied Microsoft .Net Framework Programming" by Jeffrey Richter and the information above is a rehash of the content in the book hth regards, sr ----------------------------------------------------------- To stop getting this e-mail, or change how often it arrives, go to your E-mail Settings. http://groups.msn.com/BDotNet/_emailsettings.msnw Need help? If you've forgotten your password, please go to Passport Member Services. http://groups.msn.com/_passportredir.msnw?ppmprop=help For other questions or feedback, go to our Contact Us page. http://groups.msn.com/contact If you do not want to receive future e-mail from this MSN group, or if you received this message by mistake, please click the "Remove" link below. On the pre-addressed e-mail message that opens, simply click "Send". Your e-mail address will be deleted from this group's mailing list. mailto:[EMAIL PROTECTED]
