Mapping a C# Com Interop class to fixed COM GUIDS
By Robert M. Meagher

When you create a C# class, you can make it available as a COM object to code outside of the VS.NET framework. This is done through use of the utility REGASM. REGASM creates a COM Type Library that describes the COM aspects of the class for use by both early binding in C++ (through #import directives) and late binding systems (such as VB6, through project references), and registers the COM class in the Registry under the HKLM\Software\CLSID hierarchy.

However, every time you rebuild your assembly and run REGASM on it, you will get new GUIDs (Globally Unique Identifiers) assigned for the COM Class ID, Interface ID, and Type Library ID, UNLESS you know how to assigned fixed GUIDs to these COM entities. Why does it matter if the GUIDs change? For one thing, unless you unregister the old assembly before you create the new one, old GUID entries will be left lying around in the registry. For another thing, any application that you have already built against a previously created type library generated by REGASM will be looking for out of date GUIDs in the registry, and will probably fail to load the proper assembly at runtime.

The key to specifying fixed GUIDS in C# is through C# attributes. There are three places where you need to specify an attribute to specify a different GUID: on the Interface definition for the exposed COM interface(s) for the class; on the class definition itself (the so-called COM coclass) and the type library (the so-called LIBID). You specify the following constructs for interface and coclass definitions:

using System.Runtime.InteropServices;

  [GuidAttribute("interface-guid")]
  public interface IMyCOMInterface
  {
   ...
  }

  [GuidAttribute("clsid-guid")]
  public class CMyCOMClass : IMyComInterface
  {
    public CMyCOMClass() {...} // need a public default constructor for COM
   ...
  }