The main module of an assembly is a module plus some manifest information.

Custom attribute.

Represents the efficiency-oriented storage of ILAttributes in another item.

Defines an opened namespace, type relevant to a code location. Emitted to the PortablePDB format. Note the format supports additional variations on imported things that are not yet emitted in F#.

Defines a set of opened namespace, type relevant to a code location. Emitted to the PortablePDB format.

Default Unicode encoding for P/Invoke within a type.

Event definitions.

Table of those events in a type definition.

these are only found in the ILExportedTypesAndForwarders table in the manifest

Field definitions.

Tables of fields. Logically equivalent to a list of fields but the table is kept in a form to allow efficient looking up fields by name.

Field Init

Formal identities of fields.

Field specs. The data given for a ldfld, stfld etc. instruction.

Generic parameters. Formal generic parameter declarations may include the bounds, if any, on the generic parameter.

Represents guids

Member Access

IL Method definitions.

Tables of methods. Logically equivalent to a list of methods but the table is kept in a form optimized for looking up methods by name and arity.

Method Impls

Formal identities of methods.

The information at the callsite of a method

One module in the "current" assembly, either a main-module or an auxiliary module. The main module will have a manifest. An assembly is built by joining together a "main" module plus several auxiliary modules.

Native Types, for marshalling to the native C interface. These are taken directly from the ILASM syntax. Most of these are listed in the CLI ECMA-335 Spec (Partition II, 7.4).

"Classes Elsewhere" - classes in auxiliary modules. Manifests include declarations for all the classes in an assembly, regardless of which module they are in. The ".class extern" construct describes so-called exported types -- these are public classes defined in the auxiliary modules of this assembly, i.e. modules other than the manifest-carrying module. For example, if you have a two-module assembly (A.DLL and B.DLL), and the manifest resides in the A.DLL, then in the manifest all the public classes declared in B.DLL should be defined as exported types, i.e., as ".class extern". The public classes defined in A.DLL should not be defined as ".class extern" -- they are already available in the manifest-carrying module. The union of all public classes defined in the manifest-carrying module and all exported types defined there is the set of all classes exposed by this assembly. Thus, by analysing the metadata of the manifest-carrying module of an assembly, you can identify all the classes exposed by this assembly, and where to find them. Nested classes found in external modules should also be located in this table, suitably nested inside another "ILExportedTypeOrForwarder" definition. these are only found in the "Nested" field of ILExportedTypeOrForwarder objects

Method parameters and return values.

Represents a prefix of information for ILTypeDef. The information is enough to perform name resolution for the F# compiler, probe attributes for ExtensionAttribute etc. This is key to the on-demand exploration of .NET metadata. This information has to be "Goldilocks" - not too much, not too little, just right.

Property definitions

Table of properties in an IL type definition.

Table of resources in a module.

Method return values.

Represents the efficiency-oriented storage of ILSecurityDecls in another item.

Debug info. Values of type "source" can be attached at sequence points and some other locations.

Represents IL Type Definitions.

Type Access.

A categorization of type definitions into "kinds"

Type Layout information.

Tables of named type definitions.

Indicate the initialization semantics of a type.

Type refs, i.e. references to types in some .NET assembly

Type specs and types.