The CCI Metadata Object Model

This section describes basics of the CCI Metadata mutable object model. The immutable metadata model is simply a set of interfaces that provide read-only access to the corresponding mutable object, so it is not discussed in detail. The two models are related by a naming convention. A mutable object named ObjectName has an immutable interface named IObjectName.

Assemblies and Modules

CCI applications work primarily with assemblies or modules. Assemblies are represented by an Assembly object, and modules are represented by a Module object. Assembly is a child of Module.

There are two ways to create a new object:
  • Read an existing PE file from storage, which returns an immutable object model as an IAssembly or IModule interface. As a practical matter, you can often cast the interface to IModule, because it represents either assemblies or modules. See the PeToPe sample for an example.
  • Create a new Assembly or Module object and construct the object model from scratch. For a simple example of this approach, see the HelloIL Sample Walkthrough. This example uses only the CCI metadata API, and creates code blocks as MSIL. More substantial applications would use the CCI Code Model to create the code blocks.
An Assembly or Module object is basically the root of a hierarchy. To access the elements of the object model, start with Assembly or Module and work down. There are two basic approaches:
  • The AllTypes property is a list of all types in the assembly. If you are working with an immutable representation, call GetAllTypes, which returns a collection that contains the assembly’s types. In either case, you can access the types by enumerating the list. See the FindGeneric Sample Walkthrough for an example.
  • Work your way through the namespace and type hierarchy. The UnitNameSpaceRoot property contains an IRootUnitNamespace interface that provides access to the root namespace’s child namespaces, top level types, and any other objects that implement INamespaceMember.


Namespaces are represented by objects that derive from UnitNamespace:
  • RootUnitNamespace represents root namespaces, which are the root of a hierarchy and have no parent namespace.
  • NestedUnitNamespace represents nested namespaces, which have a parent namespace.
The Members property contains a list of the namespace’s members.


Type metadata is represented by objects that derive from TypeDefinition.
  • NamespaceTypeDefinition represents types that are children of a namespace.
  • NestedTypeDefinition represents types that are nested in another type.
These objects contain a set of properties, such as IsClass and IsEnum, that indicate what kind of type the object represents. For classes, the Methods and Properties properties contain lists of the type’s methods and properties.

The InternedKey property contains the type’s unique key. You can test types for equality by comparing their InternedKey values. Otherwise, you would have to determine the structure of each type, and then compare the structures, which is much more time consuming. InternedKey values are assigned by an InternFactory object.

Methods and Properties

Method and property metadata are represented by objects that derive from TypeDefinitionMember.
  • MethodDefinition represents methods. The class includes a set of properties, such as IsGeneric or IsConstructor, that characterize the method. There is also a Body property that provides access to the method body, including the MSIL code.
  • PropertyDefinition represents properties.

Method Bodies

CCI Metadata has two ways to represent method bodies. Which one you use depends on how you want the code block to be represented.
  • Use the MethodBody class when code blocks are to be represented as MSIL.
  • Use the SourceMethodBody class when code blocks are to be represented by CCI Code representation.
Both classes include a set of properties that provide access to the code and related data, including:
  • LocalVariables contains a list of the method’s local variables.
  • Operations contains a list of the method’s MSIL instructions.
SourceMethodBody also includes a Block property that contains the CCI Code representation of the code block.

See the FindThrowPlatformType Sample Walkthrough for an example of how to work with method bodies.


Assemblies always reference mscorlib.dll, and most reference other assemblies.
  • NamespaceTypeReference represents type references.
  • MethodReference represents method references.
The Microsoft.Cci.PlatformType class is basically a container for a set of properties that contain references to standard core types, such as System.Boolean or System.String.

Return to Beginning

Last edited Jan 21, 2010 at 5:47 PM by Guy_Smith, version 1


No comments yet.