Type Information

If you think of COM in C++ terms, a ‘class’ is like a ProgID, but a client still needs something analogous to a header file to consume it (if you ignore IDispatch). There are multiple solutions to this.

Type libraries are specified in Interface Definition Language (IDL) and created using the MIDL compiler. This is a deep subject that most of us don’t need to know very much about.

The MIDL compiler is invoked on the command line. Behind the scenes, it calls CreateTypeLib2 and does most of its work through subsequent calls on ICreateTypeLib2 and ICreateTypeInfo2.

A client can inspect an existing type library by calling LoadTypeLibEx and making calls on ITypeLib2 and ITypeInfo2, and navigating the deeply nested return values.

The type library may be identified by a LIBID in the registry, or the class may implement IProvideClassInfo2

Variations

  • The full solution is to have a COM server and a separate typelib DLL. Both have entries in the registry.
  • A slight optimization - both are housed in the same binary. Both still have entries in the registry.
  • Use OLE automation with late binding and accept the runtime penalty. Only the server is registered.

Alternatives

‘Classic’ COM uses the registry, which is not a best practice because it’s system-wide. Other solutions include

  • Reg-free COM is an XML manifest.
  • .WinMD files were introduced in WinRT, which contain .NET header information. They can be read with ILDASM.

These files can be included with your project, to avoid the registry entirely.

Ignore

Compilers actually use ITypeComp to grab all the info fast and throw it into an internal table.

References