-----------------------------------------------------------
New Message on BDOTNET
-----------------------------------------------------------
From: Pooran-Prasad
Message 8 in Discussion
Hi
Sitaraman,
It was really a good read..
Thanks :)
Have a great day
:)
R Pooran
Prasad
R. Pooran Prasad
Itreya Technologies Pvt Ltd.,
Mail:
[EMAIL PROTECTED]
Phone(Off) :
5200179/80/81/82/83 Extn: 50
Mobile: +91 98860 29578
-----Original Message-----
From: SitaramanM
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2003 1:11
PM
To: BDOTNET
Subject: Re: diff between manifest and
metadata??????
New Message on BDOTNET
diff
between manifest and metadata??????
Reply
Reply to Sender Recommend
Message 6 in
Discussion
From: SitaramanM
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
View other groups in this
category.
-----------------------------------------------------------
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]
