0

My project was originally set to Binary Compatibility, but it was not building. So I first set it to No Compatibility, it built fine that way. Then I set it back to Binary Compatibility, and overwrote over the previously generated file, it worked fine.

Why does this have to happen?

MackM
  • 2,906
  • 5
  • 31
  • 45
Muhammad Farhan
  • 359
  • 2
  • 4
  • 12

2 Answers2

3

I would hazard a guess that the binary compatible location you are using is the executable itself and not a bincompat version stored.

By changing any exposed com interface within the code, binary compatibility would be broken (you can get away with extending interfaces, but not changing existing ones / types), which prevented the build.

By setting it to build with no compatibility, the checks are discarded and the executable built.

You then changed it back to binary, and this is where / why I think you are pointing binary compat version to the built exe itself and not a separate copy - so the executable was automatically compatible to itself and allowed it to build.

Jan Pfeifer
  • 2,854
  • 25
  • 35
Andrew
  • 26,629
  • 5
  • 63
  • 86
  • 1
    +1 It is recommended to keep a separate file as the binary compatible location, separate from your interim builds of the executable. Just like it says in the manual. PS Farhan, do read the manual, binary compatibility is important and it's explained well. http://msdn.microsoft.com/en-us/library/aa733706(v=VS.60).aspx – MarkJ Apr 13 '10 at 11:03
0

I think there's a bug in VB6 that can open a reference to the dll/exe and not release it so when you're using binary compatibility, so sometimes it can help to just close VB6 down, re-open it and build.

Hans Olsson
  • 54,199
  • 15
  • 94
  • 116