This is the best and concise explanation of binary compatibility I have ever
seen.
Congratulation to Trayce, ten points to you.

Binary compatibility in VB is a very delicate issue, and I am surprised that
the
documentation about it is always very confused.

I just want to add a tip to this issue:
Add the ActiveX component itself to the visual basic project as a
Related Document, so you can check in/out within VB instead of having
to keep VSS open.

Another problem: sometimes VB does not release the OCX (or DLL or exe),
so when you try to make it you get an error message (permission denied).
This is not because the component is read only, but because VB thinks that
it is still in use. To go around the problem, close all your open dialogs
and
reload the project, at this point the reference should be gone and you can
compile
again. If that still does not work, close VB and restart it.
Another solution is to have two components in two different folders, and use
one
for compatibility version and the other for the build. But, as Trayce should
know,
has much more problems than benefits, because you have to maintain two
components
instead of one, and you have to remember to copy the new version in the old
one
and check it in, because at the end of your editing session the two versions
should be
identical. Too much trouble, but still some developers prefer it.

m.


> -----Original Message-----
> From:	Trayce Jordan [SMTP:trayce@j...]
> Sent:	Wednesday, February 14, 2001 5:06 AM
> To:	professional vb
> Subject:	[pro_vb] RE: Problem: VB using VSS with custom built ActiveX
> controls.
> 
> 
> It sounds as if the project for the activex control is not using Binary
> Compatibility.
> It can be a 'pain' to have that checked, but it guarantees that the GUID
> will remain the same, so you won't have the problem any longer of 'losing'
> it and having to re-reference it.
> 
> Some tips for Binary compatibility.
> 1) The DLL must exist before you set Binary compatibility.
> 2) Make sure when selecting the DLL that it does not have any path
> information in front of it.  By default VB wants to put the path info
> there.
> If no path is specified, the PROJECT looks to the same directory as the
> project for the DLL.  That way it does not matter where the project
> resides
> on each developer's machine.  Otherwise you have to keep changing it
> everytime a developer has the project reside in a different location.
> 3)  On the MAKE DLL option, again make sure there is no path information -
> for the same reasons discussed.  That way, VB will always place the newly
> compiled DLL in the same directory as the project itself.
> 4)  Include the DLL itself into the VSS project, so that when someone
> needs
> to get the project or check-out the project, they can obtain the DLL as
> well
> for the binary compatibility check that the project must do.
> 
> Hope this helps.
> 
> 
> -----Original Message-----
> From: Bret Pelkey [mailto:bret.pelkey@a...]
> Sent: Tuesday, February 13, 2001 5:57 PM
> To: professional vb
> Subject: [pro_vb] Problem: VB using VSS with custom built ActiveX
> controls.
> 
> 
> Problem: VB using VSS with custom built ActiveX controls.
> 
> Working with a team of 3 programmers using VB 6.0 SP4 with visual
> SourceSafe
> 6.0. We have 2 projects both using the same custom ActiveX control we
> created. The problem we are having is that the ActiveX control project is
> not working with VSS. If one person opens and edits the ActiveX project
> and
> recompiles. It no longer works with the other standard project on the
> other
> work stations computers any more. The forms disappear and have to be re
> added to the project group. The only way we can get it work again is to
> get
> the latest version of the ActiveX and recompile. But this destroys the
> other
> two stations projects. (In other words a dog casing his tail) The other
> problem I'm having is that the ActiveX is only compatible with standard
> projects of last station that built the ActiveX.ocx file.
> 
> Has any one else run in to this problem?
> 
>