| Name | Description |
|---|---|
| AssemblyOSTable | This record should not be emitted into any PE file. If present in a PE file, it should be treated as if all its fields were zero. It should be ignored by the CLI. |
| AssemblyProcessorTable | This record should not be emitted into any PE file. If present in a PE file, it should be treated as if its field were zero. It should be ignored by the CLI. |
| AssemblyRefOSTable | These records should not be emitted into any PE file. If present in a PE file, they should be treated as-if their fields were zero. They should be ignored by the CLI. |
| AssemblyRefProcessorTable | These records should not be emitted into any PE file. If present in a PE file, they should be treated as-if their fields were zero. They should be ignored by the CLI. |
| AssemblyRefTable | The table is defined by the .assembly extern directive (see Section 6.3). Its columns are filled using directives similar to those of the Assembly table except for the PublicKeyOrToken column which is defined using the .publickeytoken directive. For an example see Section 6.3. |
| AssemblyTable | The Assembly table is defined using the .assembly directive (see Section 6.2); its columns are obtained from the respective .hash algorithm, .ver, .publickey, and .culture (see clause 6.2.1 For an example see Section 6.2. |
| ClassLayoutTable | The ClassLayout table is used to define how the fields of a class or value type shall be laid out by the CLI (normally, the CLI is free to reorder and/or insert gaps between the fields defined for a class or value type). The rows of the ClassLayout table are defined by placing .pack and .size directives on the body of a parent type declaration (see Section 9.2). For an example see Section 9.7. |
| CodedIndex | |
| ConstantTable | The Constant table is used to store compile-time, constant values for fields, parameters and properties. Note that Constant information does not directly influence runtime behavior, although it is visible via Reflection (and hence may be used to implement functionality such as that provided by System.Enum.ToString). Compilers inspect this information, at compile time, when importing metadata; but the value of the constant itself, if used, becomes embedded into the CIL stream the compiler emits. There are no CIL instructions to access the Constant table at runtime. A row in the Constant table for a parent is created whenever a compile-time value is specified for that parent, for an example see Section 15.2. |
| CustomAttributeTable | The CustomAttribute table stores data that can be used to instantiate a Custom Attribute (more precisely, an object of the specified Custom Attribute class) at runtime. The column called Type is slightly misleading -- it actually indexes a constructor method -- the owner of that constructor method is the Type of the Custom Attribute. A row in the CustomAttribute table for a parent is created by the .custom attribute, which gives the value of the Type column and optionally that of the Value column (see Chapter 20) |
| DeclSecurityTable | The rows of the DeclSecurity table are filled by attaching a .permission or .permissionset directive that specifies the Action and PermissionSet on a parent assembly (see Section 6.6) or parent type or method (see Section 9.2). |
| DoubleInt | |
| EventMapTable | Note that EventMap info does not directly influence runtime behavior; what counts is the info stored for each method that the event comprises. |
| EventTable | Events are treated within metadata much like Properties -- a way to associate a collection of methods defined on given class. There are two required methods -- add_ and remove_, plus optional raise_ and others. All of the methods gathered together as an Event shall be defined on the class. Note that Event information does not directly influence runtime behavior; what counts is the information stored for each method that the event comprises. The EventMap and Event tables result from putting the .event directive on a class (see Chapter 17). |
| ExportedTypeTable | The ExportedType table holds a row for each type, defined within other modules of this Assembly, that is exported out of this Assembly. In essence, it stores TypeDef row numbers of all types that are marked public in other modules that this Assembly comprises. The rows in the ExportedType table are the result of the .class extern directive (see Section 6.7). |
| FieldLayoutTable | A row in the FieldLayout table is created if the .field directive for the parent field has specified a field offset (see Section 9.7). |
| FieldMarshalTable | A row in the FieldMarshal table is created if the .field directive for the parent field has specified a .marshall attribute (see Section 15.1). |
| FieldRVATable | A row in the FieldRVA table is created for each static parent field that has specified the optional data label (see Chapter 15). The RVA column is the relative virtual address of the data in the PE file (see Section 15.3). |
| FieldTable | Each row in the Field table results from a toplevel .field directive (see Section 5.10), or a .field directive inside a Type (see Section 9.2). For an example see Section 13.5. |
| FileTable | The rows of the File table result from .file directives in an Assembly (see clause 6.2.3) |
| HeaderBase | ここにクラスの説明を書きます。 |
| ILCode | |
| ImplMapTable | A row is entered in the ImplMap table for each parent Method (see Section 14.5) that is defined with a .pinvokeimpl interoperation attribute specifying the MappingFlags, ImportName and ImportScope. For an example see Section 14.5. |
| IndexManager | ここにクラスの説明を書きます。 |
| InterfaceImplTable | The InterfaceImpl table records which interfaces a Type implements. Conceptually, each row in the InterfaceImpl table says that Class implements Interface. |
| ManifestResourceTable | The Offset specifies the byte offset within the referenced file at which this resource record begins. The Implementation specifies which file holds this resource. The rows in the table result from .mresource directives on the Assembly (see clause 6.2.2). |
| MemberRefTable | An entry is made into the MemberRef table whenever a reference is made, in the CIL code, to a method or field which is defined in another module or assembly. (Also, an entry is made for a call to a method with a VARARG signature, even when it is defined in the same module as the callsite) |
| MetadataTableCreator | |
| MethodData | ここにクラスの説明を書きます。 |
| MethodDefTable | The rows in the MethodDef table result from .method directives (see Chapter 14). The RVA column is computed when the image for the PE file is emitted and points to the COR_ILMETHOD structure for the body of the method (see Chapter 24.4) |
| MethodImplTable | ilasm uses the .override directive to specify the rows of the MethodImpl table (see clause 9.3.2). |
| MethodSemanticsTable | The rows of the MethodSemantics table are filled by .property (see Chapter 16) and .event directives (see Chapter 17). See clause 21.13 for more information. |
| ModuleRefTable | The rows in the ModuleRef table result from .module extern directives in the Assembly (see Section 6.5). |
| ModuleTable | The Generation, EncId and EncBaseId columns can be written as zero, and can be ignored by conforming implementations of the CLI. The rows in the Module table result from .module directives in the Assembly (see Section 6.4). |
| NestedClassTable | The NestedClass table records which Type definitions are nested within which other Type definition. In a typical high-level language, including ilasm, the nested class is defined as lexically 'inside' the text of its enclosing Type. |
| PEData | ここにクラスの説明を書きます。 |
| ParamTable | The rows in the Param table result from the parameters in a method declaration (see Section 14.4), or from a .param attribute attached to a method (see clause 14.4.1). |
| PropertyMapTable | The PropertyMap and Property tables result from putting the .property directive on a class (see Chapter 16). |
| PropertyTable | Properties within metadata are best viewed as a means to gather together collections of methods defined on a class, give them a name, and not much else. The methods are typically get_ and set_ methods, already defined on the class, and inserted like any other methods into the MethodDef table. |
| RVAManager | ここにクラスの説明を書きます。 |
| StandAloneSigTable | Signatures are stored in the metadata Blob heap. In most cases, they are indexed by a column in some table -- Field.Signature, Method.Signature, MemberRef.Signature, etc. However, there are two cases that require a metadata token for a signature that is not indexed by any metadata table. The StandAloneSig table fulfils this need. It has just one column, that points to a Signature in the Blob heap. |
| StreamHeader | ここにクラスの説明を書きます。 |
| TypeData | |
| TypeDefTable | |
| TypeRefTable | |
| TypeSpecTable | The TypeSpec table has just one column, which indexes the specification of a Type, stored in the Blob heap. This provides a metadata token for that Type (rather than simply an index into the Blob heap) -- this is required, typically, for array operations ・creating, or calling methods on the array class. |
