Resetting project compatibility in vb6

问题:

When we break compatibility in a vb6 dll I have to do the following:

1. Set to no binary compatibility
2. Recompile
3. Set compatibility again
4. Remove reference to changed dll from all projects that use it
5. Add reference back to all projects that use it
6. Recompile all those projects
7. Do the same for any projects that use those projects, etc.

Of course that's a little bit simplified but anyone who's done it before should know what I'm talking about.

My question is: Have you found a better way to do this, or have you found any (not too expensive) tools to facilitate this process? Or better yet, have you created one that you can share with me :)

Note that I'm asking how to make this process easier, not how to avoid it. So please don't give answers about how bad it is to break compatibility and that we shouldn't do that. I live in the real world where there are things outside of my control and I'm just trying to deal with what I've got.

回答1:

In a previous job I had, we had a huge VB6 application that contained dozens of VB6 DLLs that we referred across the projects in our project group. We were breaking compatibility often, and manually updating the references like you describe was not an option.

We initially developed a tool that would update references in all .vbp files in a folder after breaking and recompiling, but I eventually found Visual Build by Kinook Software (www.kinook.com) which could deal with this automatically.

I used their solution for many years with success. What's good about their "Make VB6" action (http://www.kinook.com/VisBuildPro/Manual/makevb6.htm) is that it can build a dependency tree and rebuild all your projects in your project group in the right order, while updating references accordingly.

For your scenario, you would need to set the "Set version compatibility before building" option to "No compatibility", and then check the "Set binary compatibility" checkbox so that projects are reverted back to binary compatibility after building.

If you have projects that you need to maintain binary compatibility for, just leave them outside the .vbg and it won't rebuild it.

回答2:

Additional Visual Basic 5.0 & 6.0 Samples offers a Binary Compatibility Add-In that could be useful. See the ReadMe.txt and Revised Binary Compatibility.doc files after "installing" it (there are steps to take after running the download).

This download includes the document "Revised Binary Compatibility" as well as the Add-in SyncCompt.dll. Binary Compatibility as implemented in Visual Basic 5.0 and Visual Basic 6.0 ensures that new versions of shipping products are fully compatible with older versions. The document explains issues around Binary Compatibility and GUID revision and introduces the DLL. The DLL add-in builds a new compatibility file to stabilize your product (except Standard EXE's which do not have binary compatibility). This tool only works in an Microsoft Windows NT® environment.

This may or may not address your issue.

回答3:

You shouldn't need to change the compatibility setting. You do however need to make sure that the dll (or exe) that you refer to in your compatibility setting is not the location you are just about to compile into.

We do something similar so we have the following structure:

C:\ProductName\Bin - contains all the live assemblies

C:\ProductName\Bin\Compatibility - contains all the assemblies as they were in the last build

After we do a build (which we do automatically by shelling VB6.exe) we move everything in \Bin to \Bin\Compatibility

回答4:

I've found the Version Compatibility in ActiveX Components series on MSDN highly enlightening on the subject of compatibility and when/how to break it. I'm posting this mainly for future reference.

回答5:

I solve the problem by not storing the compatibility information.

I remove the CompatibleEXE32={dllname} line from the .vbp files

I never save the .vbp files after a build , so that the reference does not creep back in.