Visual Basic provides three levels of compatibility for your choosing
| No Compability | Every time that you recompile your project, a new GUID is generated and assigned to each interface |
| Project Compatibility | The type library, class ids and interface ids are kept the same whenever possible. If the compatibility rules (outline shortly) are violated, then the GUIDs are regenerated. However, no validation of compatibility is performed. In other words, with Project Compatibility turned on, you can compile and release components that have the same GUIDs, but which are not compatible with previously released components. I cannot stress with enough vigor how bad it can be to do this. Not the setting of Project Compability, but releasing components that are not backwards compatible but share the same GUID. This is the kind of behavior that developers have been cursing vendors for since Windows was released. I can almost guarantee that you will spend many hours trying to figure out why your previously working application is throwing errors in weird places. Trust me on this one. The voice of experience (and many wasted hours the one time I did this) speaks. |
| Binary Compatibility | Assuming that the compatibility rules are followed, the various IDs will remain unchanged. If your project breaks compatibility while this option is set, you will receive a dialog box asking you to confirm that you want to break compatibility. The dialog box is a red flag that says you should look more closely at what you're doing. Rather than just agreeing to break compatibility, you should rethink your compatibility setting. |
Comments