VB6 binary compatibility - adding new Events

Question

In a VB6 ActiveX exe project, is there any way to preserve the GUID for the events dispinterface if and when new events are added?

Obviously changing existing events breaks compatibility. Adding a new one doesn't cause the VB6 IDE to issue a warning. This doesn't really surprise me, though, as it also doesn't warn when you add new methods but at least the existing methods retain their GUIDs.

With events, there seems to be no way to retain backwards compatibility for existing ones if new ones are added later.

This doesn't seem to be an issue for VB6 applications integrating via COM; I assume the VB runtime does something clever to pick up on the events via the registry without needing to know the GUID up-front.

Where the other app is .Net (specifically C#) and I have to declare the interface by hand in order to implement the event sinks, I want the GUID to remain constant to avoid the need for re-coding the i/f whenever the VB6 app is extended. I may neither know nor care about the newly-implemented events in the VB6 app - I just want to be able to continue to use the pre-existing ones without needing to change the .Net source code.

Is there some VB6 trick that I'm missing out on that would enable me to do this?

Answer 1

I've never found a way to prevent broken compatibility when adding events. Unfortunately, this is one of those things that I have to get right the first time (get all my new events, parameters, etc.) so that when I break compatibility, I only have to go through that pain once.

Answer 2

I'm afraid I haven't found any way of keeping the GUID constants when changing events either.. but if you're only using the VB6 assembly in a .NET app, can you just tlbimp the VB6 dll each time you recreate it, then create a reference to that instead of writing the interface in .NET by hand?

Answer 3

The problem is that once defined a COM interface is invariant. However COM has versioning so that a older interface can be setup as compatible with a new interface.

What Visual BASIC does behind the scene is creates a NEW version of the com interface. Update the version number, adds the new methods and setup the needed info so that the new interface can be automatically used with the older interface.

As it pointed out it looks like that Events are not done automatically. I used Visual Studio OLE/COM Object View and see the GUID change.

A possible solution for a hybrid VB6/.NET is a bit of pain but keeps everything clear as to when you make changes. First you need need to use the OLE/COM Object view to get the IDL of the VB6 object. Then use the MIDL compiler to generate a typelib. From now on use the typelib as your reference.

You will have to rename the interface as it will conflict with VB6 Name. The idea is that both the .NET and the VB6 will reference the typelib and implement the interfaces. Anytime you want to update the interface you change the IDL, recompile the typelib and implement the interface for both.

Now if this sound a bit complex and leave going WFT!? I don't blame you. But in my own conversion project I found it useful in certain circumstances when the VB6 stuff still has ongoing development but you need to use it in .NET

Now a simplifier solution could be to identify and separate the minimum needed for two components to interoperate. Say the events and some properites. Generate the IDL for that interface. Compile a typelib and use that as the reference. I have done that as well.