6

When I try to rebuild one of my VB6 DLLs, I get a warning:

"The binary compatibility DLL or EXE contains a parameter type or return type whose definition can not be found"

I have to release a few changes in selected DLLs (simple changes internal to methods - nothing that breaks the compatibility according to this)

The generally accepted method which I have followed is to maintain the old DLLs in a separate shared directory and while making the new DLLs, compile them with binary compatibility set to the old set of DLLs. This is done to not change the GUIDs while I register my new DLLs. These GUIDs are used as references in other DLLs which I have not disturbed during the release.

I'm pretty sure I didn't add anything to break the binary compatibility rule (No change in signature, public methods, variables etc.) Why is this error occurring?

Am I being a noob by not checking something basic? Scratching my head since morning. Any help is much appreciated.

EDIT: If at all there are changes to my signature, Is there a way that I can know without comparing code?

Community
  • 1
  • 1
maverick
  • 63
  • 2
  • 6
  • 1
    It is possible that your code broke compatibility earlier. VB6 doesn't warn, when you add any new public method or property, but subsequent compiles create different typelibs - because your reference DLL doesn't contain this new method yet. (I'm often setting dll compatibility to dll itself.) I think (but have not experienced) that specific message (... definition can not be found) may indicate some change in project references or you have uninstalled/unregistered some other component from your system. – Arvo Apr 03 '13 at 06:32
  • 2
    You binary compatibility target uses types from external typelib (probably another VB6 project) that is not correctly registered on the build machine or is a new/old incompatible version. – wqw Apr 03 '13 at 22:29
  • @Arvo - Yes it is possible that the code broke earlier. In that case, there should be at least two typelibs (one for before break and one for after). But my registry contains only one – maverick Apr 05 '13 at 17:12
  • @wqw Actually I do my builds on the same machine. I suspected that some types that are referenced by the DLL in question may have issues. But when built separately, they don't give me any problem at all. – maverick Apr 05 '13 at 17:16

1 Answers1

2

Take your old DLLs and add a compat_ prefix to them.

Basically rename your MyAppDataAccess.dll file to compat_MyAppDataAccess.dll.

Now go to the properties of your ActiveX DLL and set your project to have binary compatibility with the new compat_MyAppDataAccess.dll, like below.

Now just build your DLL and deploy it.

It should work. If, in fact you binary compatibility would be broken as a result of your changes, then you'll get a warning stating that.

enter image description here

Matt Wilko
  • 26,994
  • 10
  • 93
  • 143
AngryHacker
  • 59,598
  • 102
  • 325
  • 594
  • Wouldn't that be like referencing the same DLL to itself? Not sure if that's a good way to go. Sounds scary. Won't i have to register both of them? – maverick Apr 05 '13 at 17:26
  • Essentially, yes, but why would it be scary? You wouldn't have to register both of them. The `compat_` is only there to provide binary compatibility - you don't have to distribute it. I have a bunch of VB6 apps that have a ton of library dependencies and this is an only way to ensure that the libraries don't break binary compatibility. – AngryHacker Apr 05 '13 at 18:13
  • Ok! This works. I created a separate folder for my compatible DLLs in a shared location. Accepting the answer since it solved my problem. Thanks – maverick Apr 06 '13 at 07:18