What are the CoClass interfaces in imported assemblies specifically for?

Question

Importing a base type library using the tlbimp.exe tool always creates an interface for each coclass . For example, this is an IDL description

 interface IFoo : IUnknown { HRESULT DoSomething(); } coclass Bar { [default] interface IFoo; } 

leads to:

• IFoo interface as a representation of the COM interface,
• the BarClass class as a representation of a COM class and
• Bar interface annotated with CoClassAttribute .

If GUIDs Bar and IFoo are equal. In this section of MSDN :

This interface has the same IID as the default interface for the class. Using this interface, clients can always register as event listeners.

This is the only thing I have found on this subject. I know that due to CoClassAttribute I can use the interface to instantiate the actual class. I also know that (practically) I can just use BarClass to create a new instance of the class. I do not understand why the import process creates the Bar interface, even if coclass does not determine the source of the event, and therefore the event receiver cannot be connected to it.

Is it possible to remove the Bar ¹ interface in this example or some other risks that I have not yet considered?

^{1 _{For example, disassemble the interaction assembly .}} sub>

Answer 1

You have the wrong names, which does not help to understand what is happening. The Bar component in the type library generates the Bar interface and the BarClass class, there is no "FooBar".

This is just an extra glue that type library automatically generates to make porting code simpler. Especially important for VB6 code, it required more freedoms with the COM object model. VB6 uses a class as if it were a real implementation class. There is no such thing in COM; a class is an opaque place for a class; these are interfaces that do all the work. VB6 never supported the concept of interfaces, so direct COM modeling in code was not possible.

The VB6 compiler itself generates a code class from the Class keyword in the code and generates an interface that contains the actual methods and properties. This interface is hidden, it has the same class name, but with a leading underscore. By convention, this causes object browsers to hide the interface. This way your Bar style, written in VB6, will generate the _Bar interface.

Thus, the converted VB6 program will use Bar everywhere. This will not compile unless Bar is replaced by IFoo. The synthesized Bar interface comes to the rescue, avoiding the need for it.

It remains to solve two problems fixed by the synthetic BarClass type. New Bar() will not compile because instantiating an interface is not legal. The compiler solves this problem; it automatically replaces "Bar" with "BarClass". What is the actual role of the [CoClass] attribute, it provides a name for the class associated with the interface. And events are a problem, they are implemented in COM using the dispinterface. Again, a separate interface with an intricate mechanism under the hood that signs events (IConnectionPoint, etc.). The synthetic BarClass makes them realistic. NET events.