Can someone please explain Version Compatibility to a new to VB person

Please excuse the novice request! Can someone explain Version Compatibility (No compatibility, Version compatibility, binary compatibility) in non-MS-Speak? I've read the little I could find in the help, but it's not making it any clearer for me.

I'm specifically trying to figure out when I want to use which type of compatibility.

Any good reading would be appreciated!

Many Thanks,
cin

i'll let MS explain it :D

sorry if it sounds complex...

Quote:

---

When Should I Use Version Compatibility?


Visual Basic provides two mechanisms for maintaining backward compatibility while enhancing software components — the Version Compatibility feature and the Implements feature.

Version Compatibility
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:

No Compatibility: Each time you compile the component, new type library information is generated, including new class IDs and new interface IDs. There is no relation between versions of a component, and programs compiled to use one version cannot use subsequent versions.


Project Compatibility: Each time you compile the component the type library identifier is kept, so that your test projects can maintain their references to the component project. All class IDs from the previous version are maintained; interface IDs are changed only for classes that are no longer binary-compatible with their earlier counterparts.
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.

Binary Compatibility: When you compile the project, if any binary-incompatible changes are detected you will be presented with a warning dialog. If you choose to accept the warning, the component will retain the type library identifier and the class IDs. Interface IDs are changed only for classes that are no longer binary-compatible. This is the same behavior as Project 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.

Using the Implements Statement for Compatibility
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 Chapter 6, "General Principles of Component Design," and in "Polymorphism" in Chapter 9, "Programming with Objects," in the Visual Basic Programmer’s Guide.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.

When to Use Version Compatibility Options
If you decide to use the Version Compatibility feature, you may find the following rules helpful in determining when to use the different options:

Use No Compatibility to Make a Clean Break
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:

Change the file name of your component, so that the incompatible version won’t over-write earlier versions on your users’ hard disks.


Change the Project Name on the General tab of the Project Properties dialog box, so that the incompatible component will have a different type library name. This ensures that the objects the component provides will have unique programmatic IDs.
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 Project Compatibility for New Development
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."

Use Binary Compatibility for New Versions of Existing Components
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."

Don’t Mix Binary Compatibility and Multiple Interfaces
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 Chapter 6, "General Principles of Component Design," for information about component software design using multiple interfaces.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.

---

The best compatibility to use in most cases is going to be binary compatibility. Here's the difference between them:

No Compatibility - VB will not check to see if a component is compatible with any other version of the component or project. Don't ever use this.

Project - The component will only be compatible with the project it was compiled with. This type of compatibility would be fine for cases where you've created a custom component to do very specific work and probably wouldn't use it in any other project without major modification.

Binary Version - VB will check each time you compile the component if the version of the component has changed. If so, it will warn you that this version of the component may not (most likely won't) work with older programs compiled to use an older version of the component. The version of the component would change if you added, deleted or changed the Public Interface to the component. That is arguments, names or return types of public methods or properties. Changing the "guts" or private variables do not affect the public interface and so do not change the version.


Sorry if this is still too technical, but it's difficult to explain in "simple" terms. Bottom line is that you will likely want to use binary compatibility 9 times out of 10 because this will allow for the greatest reuse from project to project. Plan the component interface well in the beginning and you shouldn't have much of a problem with compatibility.

This is for COM.

The idea is this: you 'know' that typing on the keyboard will make letters appear in an edit box on the screen. Everytime you go to a PC, this always works. You do not have to think about it.
This is the idea behind binary compatibility.

What you have is a COM interface. The rules by which it works (like typing on the keyboard) never change - the keys are in the same place all the time - binary compatibility.

One day you come in and the keys have been moved around.
You have just gone from binbary to version. The system works generally the same but the buttons moved.

COM has buttons - an interface has function pointers that are always in the same place and work the same way -binary.
Move the order of the functions or change their arguments and you go to a new version.

No compatibility - you come to your PC and there is no keyboard, just a foot switch. So, now you can't use the PC at all because its setup defeats your understanding and your assumptions about how things work. This is what happens to a client that uses one interface, when presented with an all new one.

The reason for all this: the interface to a COM server is like a black box with blank buttons on it. The client expects certain things to happen when it 'pushes' button #8.

An interface is a binary contract. You break the contract, you lose.

Jim's hit the nail on the head . . .

What he was talking about is something called an IUnknown interface which is essentially a concrete 'contract' of how components cooperate with each other.

The IUnknown interface implementation (the VB component) builds a table (vtable) of where in memory these functions are so that it can locate them, and ultimately execute them. This table is fixed in size and function order which means it cannot change once it's definition is built into the VB executable.

However VB allows you to re-write this table everytime you compile without ever knowing about it. This means the component will possibly change it's table definition and will always change the unique identifiers that relate to this table and other relevant parts of the component - this is called no compatibilty because your component will now not be compatible with any other component that was compiled against the old definiton.

Binary Compatibility forces the VB compiler to maintain the table definition if it hasn't changed, and never to regenerate the pointers, and unique references. This is why you will get Compatibility issues if you change any function stubs in the component. If you allow a binary compatible component to change it's definition you risk breaking existing clients, and walking into the realms of interface forwarding which is a nighmare.

However you don't need to use IUnknown - you can use an interface called IDispatch which has a special behind-the-scenes call which queries the interface at run time in order to determine whether the function call can be made. The drawback to convenience is, as always, execution that is slower by orders of magnitude.

The differences are more clear to me now!

Thanks for your time!!

cin