When working with ActiveX DLLs, many VB programmers build a reference DLL first, copy it to a subdirectory of the project directory, and set version compatibility to binary with a pointer to the reference build. Many of these same programmers believe-or have been taught-they can now forget about compatibility because VB prevents them from ever building an incompatible version. They’re dead wrong. Suppose you later add a method to one of the public classes in the project, which is defined as:
Public Sub DoSomething(Prm1 As String, _ Prm2 as Integer)Version 2, which includes the new DoSomething method, is built without VB complaining, because the new build is version-compatible. For example, you might modify and recompile client applications to take advantage of the new method.Suppose you change the Prm2 parameter of DoSomething from Integer to Long to prevent an overflow error. Ordinarily, such a change breaks backward compatibility. But, because the reference build is version 1, which doesn’t have the DoSomething method, VB assumes it’s completely new and happily builds version 3. The truth, however, is that this change does break compatibility, and all the client applications of version 2 crash with runtime error 430, “Class doesn’t support Automation.”
Changing a parameter’s type isn’t the only way a programmer can fool VB into thinking it’s maintaining binary compatibility. In fact, removing or changing any method or property that wasn’t in version 1 does it, as well as removing a class that wasn’t in version 1.
When working with ActiveX DLLs, the only way to ensure ongoing compatibility is by updating your reference build after each change in the interface(s) it exposes. You should always point the reference to your last-shipped build, which assures that each version is compatible with the last-shipped version.
