Possible consequences of duplicate ProgId for different classes

Question

In a software I'm maintaining I've observed COM classes marked with identical [ProgId]s.

AFAIK the ProgId is a human readable identifier for a component and it should map 1-to-1 with the component's CLSID.

So I'm wondering:

• Is there any good reason to have the same ProgId for different classes?

• What are the possible consequences? (except not being able to reach a component using this convenient way)

Thanks in advance.

Answer 1

A ProgId provides a friendly name for the CLSID guid of a coclass. Important to scripting languages, no good way to know the guid. Also used by languages that support late binding, like VB.NET and C#. The conversion from the string to the guid happens at runtime. The usual name of the factory function is CreateObject(), the language runtime implements it by looking at the registry entry stored in HKLM\Software\Classes.

Which is your cue to what will go wrong when you duplicate them. The actual object the client program creates is random. Whichever one happened to be registered last. The client program calls a completely different method from the one it intended to call. This might trigger a DISP_E_Xxxx error return but that's certainly no guarantee. In general a very nasty and quite undebuggable mishap.

The only way you can not have this problem is when the client code uses early binding and uses the type library to know the guids. That's not unusual but it is not in your control. If you know that the client code doesn't use them then simply omit the [ProgId] attribute so no accidents can happen.