9

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.

mmmmmm
  • 32,227
  • 27
  • 88
  • 117
Brandon Moore
  • 8,590
  • 15
  • 65
  • 120
  • 1
    Take a look at http://users.skynet.be/wvdd2/Compiling/The_Way_we_Work/the_way_we_work.html – wqw Nov 18 '11 at 14:12

5 Answers5

9

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.

Gabriel
  • 3,733
  • 16
  • 29
  • Sweet. Will definitely mark this as the answer if someone else doesn't come up with something that's free in the next 24 hours... which I highly doubt :) – Brandon Moore Nov 18 '11 at 02:01
  • Unfortunately I'm not going to even spend that much money right now, but I'll mark yours the answer anyway cause it looks like it does exactly what I want. – Brandon Moore Nov 18 '11 at 16:21
3

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.

Bob77
  • 13,167
  • 1
  • 29
  • 37
1

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.

Doc
  • 343
  • 3
  • 13
1

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

Matt Wilko
  • 26,994
  • 10
  • 93
  • 143
  • Brandon wants to *break* compatibility – MarkJ Nov 18 '11 at 11:45
  • @MarkJ yes this will break compatibility because it is comparing with the previous version to which it may or may not be compatbile. When you use the VB6.exe to compile you will not get any GUI asking if you want to continue - it just continues regardless – Matt Wilko Nov 18 '11 at 13:19
  • Maybe I don't understand. I'm assuming you have binary compatibility switched on and the reference binary is in `Bin\Compatibility`? You build into `Bin`. So the binaries in `Bin` are binary-compatible with `Bin\Compatibility`. Then you copy the binaries in `Bin` into `Bin\Compatibility`. So now, when you build again, your new binaries are binary-compatible with the binaries in `Bin\Compatibility` i.e. all previous builds. This is a method for *keeping binary compatibility* forever, not for breaking it. Or have I misunderstood? – MarkJ Nov 18 '11 at 14:55
  • @markj Well they may or may not be compatible with the ones in the `Bin\Compatibility` directory - this is the location for comparison so VB knows whether a compile will or won't break compatibility. – Matt Wilko Nov 18 '11 at 15:07
  • It´s the location for the reference binaries. VB either: (1) compiles successfully and creates versions that are binary compatible. Or, (2) if you´ve *made code changes* that mean it cannot be sure that the new build will be compatible, VB prompts you to decide what you wish to do. But Brandon wants to *deliberately break compatibility*, even though he has *not* made any code changes that force incompatibility. – MarkJ Nov 18 '11 at 15:38
  • @Markj Oh ok then that is slightly different but begs the question why on earth would you *want* to break compatibility? – Matt Wilko Nov 18 '11 at 15:42
  • @Matt We don't 'want' to break compatibility, but it happens. For example when we installed the Win7 sp2 it broke the MDAC because *Microsoft* broke their own interface. They provided a backward compatible typelib to use, but switching references still broke compatibility. There are other times when things aren't compiling quite correctly and certain people aren't smart enough to figure out what's wrong. Rather than them spending 6 hours doing that, I wish they could just have a tool that just makes it work even if that means breaking compatibility. – Brandon Moore Nov 18 '11 at 16:18
  • @MarkJ Theoretically, Matt may be on to something. What if I compiled a dll with nothing in it to use for compatibility and then never updated it when we make new releases. That should keep vb from complaining when I make a breaking change cause it won't be able to tell, and it will retain the old UUID. But would that keep the code that references a changed dll from complaining? – Brandon Moore Nov 18 '11 at 16:27
0

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.

Kirsten
  • 15,730
  • 41
  • 179
  • 318