How do I tell vb6 not to create new versions of interfaces/com objects everytime I make dll?

Question

I have vb6 com server (ActiveX DLL project) that is used by .NET code

Everytime I put changes into vb6 code and make dll, I have to recompile my .NET client code as well, because it looks like VB6 generates new GUIDs or versions to interfaces and com-objects.

I admit it's a good practice because changes are made but I'd like to disable this behavior to let my .NET client code be the same everytime I update my vb6 dll.

How can I tell VB6 to keep all GUIDs and versions for ActiveX dll the same no matter what changes are done to COM objects or COM interfaces?

Answer 1

The selection in the Project + Properties, Components tab matters. You have to select "Binary compatibility" here to force it to re-use old guids. And keep a copy of the DLL around to act as the "master" that provides the guids, check it into source control.

When you add new classes then you also have to update that copy so future versions will know to reuse the same guids for those added classes. Easy to forget, pretty hard to diagnose when you do.

It is very dangerous, reusing guids is a very strong DLL Hell inducer. You can get old client programs to continue using the new DLL as long as you careful avoid changing existing methods. Not just their method signature but also their implementation. An updated client that encounters an old version of the DLL will fail in a very nasty way, the access violation crash is near impossible to diagnose.

Answer 2

Using Binary Compatibility only buys you so much. Maintaining interface compatibility over the long term only works well for very simple libraries or when your interfaces were very well planned and future-proofed from the beginning. It can be scary to look at some peoples' VB6 libraries and see interface version numbers in the high hundreds (both GUIDs and version numbers are used to identify an interface) even when they think they've carefully managed Binary Compatibility.

It can get even worse when you have a system of programs that share libraries. A new requirement or even a bug fix might require a breaking change to a library's interface for one program but not the other 12 or 20 of them.

You have to accomodate this by explicit manual versioning, where you actually change the name of the library to reflect a new version with an entirely new set of GUIDs. Often this is done with numbering, so that a ProgId like "FuddInvLib1.DalRoot" can coexist side by side with a new "FuddInvLib2.DalRoot" in two libraries with entirely different sets of GUIDs: FuddInvLib1.dll and FuddInvLib2.dll.

As each is changed for support purposes you can maintain Binary Compatible versioning within each of them over time, eventually phasing out the FuddInvLib1.dll entirely. This of course means migrating client code to use the newer library or libraries over time, but you have the luxury of doing this incrementally at a planned pace.