views:

93

answers:

2

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?

+2  A: 

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 compatability 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 compatability, 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 seperate copy - so the executable was automatically compatible to itself and allowed it to build.

Andrew
+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
Many thanks for your help guys! :)
Farhan
A: 

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.

ho1
No, re-opening and building doesn't work for me.
Farhan