I am wondering if anyone else has experienced this before.

I build a UserControl (Test.ocx) and it is my version
1.0.00 .

     When I upgrade and build 1.1.00 , I set binary
compatibility to the 1.0.00 control.  Everything is still
fine up to this point.  All apps built using the 1.0.00
control are compatible with the 1.1.00 control.

     The name of my control is Test.ocx.  When I move up
to version 1.2.00, I check a file into my code repository
called CheckedInTest.ocx.  This actually is a renamed
Test.ocx from my version 1.1.00.  When I build the
usercontrol with version 1.2.00 it is compatible with all
1.1.00 controls and 1.0.00 controls.  The problem occurs
when I rebuild the 1.2.00 UserControl.  All of a sudden,
it stops being compatible with the last build (NOT last
version) of itself.  This even happens if no code changes
have been made and no project settings have been changed.

     Is there any way around this without having to set
the binary compatibility equal to Test.ocx?  Any help,
feedback, ideas would be greatly appreciated.

                    -Evangelos Angelides

You absolutely need to keep the compatibility model up to date. As soon as
you add a new public interface, you need to update the model. If you don't,
VB will generate new information for that new interface each time you
compile... even if nothing changes... as far as VB's concerned, it did it's
job by remaining compatible with the DLL you're pointing to.

DLL V1.00 has method A
EXE uses A

DLL V1.10 has method A and B
The EXE that uses A still works ('cause you're compatible with 1.00)
EXE uses B

DLL V1.20 has method A and B
The EXE that uses A still works ('cause you're compatible with 1.00)
The EXE that uses B bombs because method B wasn't defined in the
compatibility model.