VB6 / COM Interop: where do these events come from?

Question

I wrote a COM-visible class library in C # 4.0 that I use with VB6. It only works if I open the VB6 object browser and look at the participants, I see an event for each open participant ... but the C # code does not define any of them .

This is normal? Am I doing something wrong?

[ClassInterface(ClassInterfaceType.None)] [ComSourceInterfaces(typeof(IMyClass))] public class MyClass : IMyClass { public void DoSomething(string someParam) { ... } } public interface IMyClass { void DoSomething(string someParam); } 

The node is signed with a strong key and AssemblyInfo.cs has the [assembly: ComVisible(true)] attribute, but I'm not sure if it has anything to do with the problem.

When I look at the object browser in VB6, I expect to see DoSomething(string) as a member of MyClass , and I will do it, however I also see an event with the corresponding signature for each public method, like Event DoSomething(someParam As String) as a member of MyClass .

Even more perplexing (at least for me), properties also have a “comparable” event (you can only tell by the small lightning bolt) - if MyClass defined a property like this:

 public string SomeProperty { get; set; } 

In the VB6 object browser, it will be indicated that the "event" is defined as Property SomeProperty As String , which leaves me stunned - how is the "property" duplicated 1) and 2) is the duplicate displayed with the "event" icon in the object browser? The same applies to get-only properties that have their read-only property / event instance.

Where do these events come from and how can I get rid of them?

UPDATE An image is worth a thousand words:

UPDATE The ComSourceInterfaces attribute was ComSourceInterfaces , which was mistakenly used instead of the ComDefaultInterface attribute. Switching the first for the last gives the expected result:

Answer 1

By typeof(IMyClass) as an argument to the ComSourceInterface attribute, you say that everything in IMyClass is an event.

If you do not want the event interface for your class to remove the ComSourceInterface attribute.

If you do want to output events from your C # class to VB, follow these steps:

When creating a COM visibility class, you will also want to create an interface that defines only event handlers for your class. Your class should be decorated with a COMSourceInterface defining your event handler interface, and it should define your events and implement the event handler interface. See How: Raise events handled by the COM shell for another example.

 [GuidAttribute("1A585C4D-3371-48dc-AF8A-AFFECC1B0967") ] [InterfaceTypeAttribute(ComInterfaceType.InterfaceIsIDispatch)] public interface MyEvents { void ConnectedEvent(string state); } [ComSourceInterfaces(typeof(MyEvents))] public class MyClass { public event Action<string> ConnectedEvent; public MyClass() { } public void DoSomething(string state) { if (ConnectedEvent != null) ConnectedEvent(state); } } 

See also: Murat Angle: View COM Events

Answer 2

You will basically find out that in COM there is nothing special about events. As in COM, events are supported by the interface. The only thing special about the interface that defines the event methods is that it is marked with the [source] attribute in the type library. This is all the [ComSourceInterfaces] attribute does, recognized by Tlbexp.exe when generating the type library.

There is nothing special about COM properties. They work just like in .NET, they are implemented using methods. Getter and setter method.

So, VB6 looks at your type library and is happy with the class that has the events, since it has an interface with the [source] attribute. And he is glad that the interface has methods, everything that they can ever have, so he assumes that these are methods that are triggered when an event occurs. Of course, it is not wise enough to admit that these methods are also accessories for the property; he assumes that the author of the type library knows what he is doing.

Events are called “junction points” in COM. Google IConnectionPoint to learn more about this. If you have ever created a WinRT component with custom event assemblers, you will also see that COM events have little to do with .NET events.

Anyhoo, the workaround is simple, use only [ComSourceInterface] when creating events.