Visual Basic provides two mechanisms for maintaining backward compatibility while enhancing software components — the Version Compatibility feature and the Implements feature.
Visual Basic’s Version Compatibility feature is a way of enhancing your components while maintaining backward compatibility with programs that were compiled using earlier versions. The Version Compatibility box, located on the Component tab of the Project Properties dialog box, contains three options:
Note This is a change in Project Compatibility from Visual Basic 5.0, where all class IDs and interface IDs in the project changed if any one class was no longer binary-compatible.
Important For the purpose of releasing compatible versions of a component, Project Compatibility is the same as No Compatibility.
If, however, you choose to ignore the warning, the component will also maintain the interface IDs. This option is only available when the compiler determines that the change was in the procedure ID or signature of a method.
Caution You should only choose the Ignore button if you are absolutely sure that the changes you have made won't break compatibility. If you aren't absolutely sure, take the safe alternative and choose the Accept button to allow the interface ID's to be changed.
Important The option to override the compiler's warning represents a change in behavior from Visual Basic 5.0. It is important that you fully understand the implications of incompatible changes before proceeding with this option.
Note When people talk about Version Compatibility, they’re usually referring to Binary Compatibility.
The appropriate use of these options is described below.
The Implements statement allows you to add multiple interfaces to class modules, as described in "Polymorphism, Interfaces, Type Libraries, and GUIDs" and "Providing Polymorphism by Implementing Interfaces" in "General Principles of Component Design," and in "Polymorphism" in "Programming with Objects," in the Visual Basic Programmer’s Guide.
Multiple interfaces allow your systems to evolve over time, without breaking existing components or requiring massive re-compiles, because a released interface is never changed. Instead, new functionality is added to a system by creating new interfaces.
This approach is much more in keeping with the design philosophy of the Component Object Model (COM), on which the ActiveX specification is based.
Note The Binary Compatibility option of Version Compatibility is useful in conjunction with Implements and multiple interfaces, to prevent changes to the default interfaces of your classes.
If you decide to use the Version Compatibility feature, you may find the following rules helpful in determining when to use the different options:
When you begin working on a new version of an existing component, you may decide that the only way to make necessary enhancements is to break backward compatibility. In this case, set No Compatibility the first time you compile your project. This guarantees that you’ll start with a clean slate of identifiers, and that existing programs won’t mistakenly try to use the incompatible version.
Before compiling an existing project with No Compatibility, you must also:
These items are discussed in more detail in "Levels of Binary Version Compatibility."
After compiling once with No Compatibility, switch to Project Compatibility to simplify your development tasks.
Use the Project Compatibility setting when you’re developing the first version of a component. Project Compatibility preserves the type library identifier, so that you’re not continually setting references from your test projects to your component projects.
Using Project Compatibility also makes it easier to switch between the component project and the compiled component when you’re testing.
Project Compatibility is discussed in "Project Compatibility: Avoiding MISSING References."
Switch to Binary Compatibility mode when you begin work on the second version of any component, if you want applications compiled using the earlier version to continue to work using the new version.
Switching to Binary Compatibility is discussed in the related topic "Providing a Reference Point for Compatibility."
If you use multiple interfaces and the Implements statement to provide backward compatibility, don’t use Binary Compatibility to modify the abstract interfaces you’ve defined for use with Implements.
If you enhance any of the interfaces in a component, Visual Basic will change their interface IDs. The technique of evolving component software by adding interfaces depends on interface invariance. That is, an interface once defined is never changed — including the interface ID.
For More Information See "Providing Polymorphism by Implementing Interfaces" in "General Principles of Component Design" for information about component software design using multiple interfaces. "Maintaining Binary Compatibility" describes the versioning system Visual Basic uses to prevent compatibility problems.