free qr code library vb.net A Brief Look at Metadata in .NET framework

Encoder QR Code JIS X 0510 in .NET framework A Brief Look at Metadata

Now we know what kind of PE file we ve created . But what exactly is in the Program .exe file A managed PE file has four main parts: the PE32(+) header, the CLR header, the metadata, and the IL . The PE32(+) header is the standard information that Windows expects . The CLR header is a small block of information that is specific to modules that require the CLR (managed modules) . The header includes the major and minor version number of the CLR that the module was built for: some flags, a MethodDef token (described later) indicating the module s entry point method if this module is a CUI or GUI executable, and an optional strong-name

2

digital signature (discussed in 3) . Finally, the header contains the size and offsets of certain metadata tables contained within the module . You can see the exact format of the CLR header by examining the IMAGE_COR20_HEADER defined in the CorHdr .h header file . The metadata is a block of binary data that consists of several tables . There are three categories of tables: definition tables, reference tables, and manifest tables . Table 2-1 describes some of the more common definition tables that exist in a module s metadata block .

TABLE 2-1

Always contains one entry that identifies the module . The entry includes the module s file name and extension (without path) and a module version ID (in the form of a GUID created by the compiler) . This allows the file to be renamed while keeping a record of its original name . However, renaming a file is strongly discouraged and can prevent the CLR from locating an assembly at runtime, so don t do this . Contains one entry for each type defined in the module . Each entry includes the type s name, base type, and flags (public, private, etc .) and contains indexes to the methods it owns in the MethodDef table, the fields it owns in the FieldDef table, the properties it owns in the PropertyDef table, and the events it owns in the EventDef table . Contains one entry for each method defined in the module . Each entry includes the method s name, flags (private, public, virtual, abstract, static, final, etc .), signature, and offset within the module where its IL code can be found . Each entry can also refer to a ParamDef table entry in which more information about the method s parameters can be found . Contains one entry for every field defined in the module . Each entry includes flags (private, public, etc .), type, and name . Contains one entry for each parameter defined in the module . Each entry includes flags (in, out, retval, etc .), type, and name . Contains one entry for each property defined in the module . Each entry includes flags, type, and name . Contains one entry for each event defined in the module . Each entry includes flags and name .

As the compiler compiles your source code, everything your code defines causes an entry to be created in one of the tables described in Table 2-1 . Metadata table entries are also created as the compiler detects the types, fields, methods, properties, and events that the source code references . The metadata created includes a set of reference tables that keep a record of the referenced items . Table 2-2 shows some of the more common reference metadata tables .

TABLE 2-2

Contains one entry for each assembly referenced by the module . Each entry includes the information necessary to bind to the assembly: the assembly s name (without path and extension), version number, culture, and public key token (normally a small hash value generated from the publisher s public key, identifying the referenced assembly s publisher) . Each entry also contains some flags and a hash value . This hash value was intended to be a checksum of the referenced assembly s bits . The CLR completely ignores this hash value and will probably continue to do so in the future . Contains one entry for each PE module that implements types referenced by this module . Each entry includes the module s file name and extension (without path) . This table is used to bind to types that are implemented in different modules of the calling assembly s module . Contains one entry for each type referenced by the module . Each entry includes the type s name and a reference to where the type can be found . If the type is implemented within another type, the reference will indicate a TypeRef entry . If the type is implemented in the same module, the reference will indicate a ModuleDef entry . If the type is implemented in another module within the calling assembly, the reference will indicate a ModuleRef entry . If the type is implemented in a different assembly, the reference will indicate an AssemblyRef entry . Contains one entry for each member (fields and methods, as well as property and event methods) referenced by the module . Each entry includes the member s name and signature and points to the TypeRef entry for the type that defines the member .