The bizarre tale of a CLSID

[ralph]

We have a group containing one executable and five DLLs. The application is
a modest MDI with a couple of grid controls and using ADO. Nothing remarkable,
nothing exotic. The DLLs were used as "regular" inproc libraries. The group
and all the pieces were loaded into VSS (keeping their respective folders,
etc.

Another programmer did a get on the project, rebuilding the project on his
machine. First error was that the project wouldn't compile because "A.dll
has a binary compatible set file." <?> It went downhill from there...
complaints about "binary compatiblity", "Bad type library", can't find UDT,
etc.

Opening OLE Viewer we discovered that two of the DLLs had the same CLSID!
The other GUIDS were all different. In addition the info for both were practically
the same except for the filename and path! i.e., it is not likely that VSS
corrupted the files. They were both prefectly good DLLs - they just couldn't
exist together on the same box.

I feel there is probably no answer to this, but my client would like to know
how it happened and if this can happen again? So has anyone else ever seen
this and knows how it can happen?

Any ideas?

[Anthony Jones]

Ralph,

It sounds like the other programmer had reset the binary compatibility
settings for the projects. S/He wouldn't have happened to accidently
pointed two of the projects at the same dll? I haven't tried this to see
what would happen but it could account for both projects having the same
'CLSID' (assuming you actually ment type lib ID).

Just a guess.

--
Anthony Jones
Nuesoft Ltd

[ralph]

"Anthony Jones" <anthony.jones@nonuesoft.spamco.uk> wrote:
>Ralph,
>
>It sounds like the other programmer had reset the binary compatibility
>settings for the projects. S/He wouldn't have happened to accidently
>pointed two of the projects at the same dll? I haven't tried this to see
>what would happen but it could account for both projects having the same
>'CLSID' (assuming you actually ment type lib ID).
>
>Just a guess.
>
>--
>Anthony Jones
>Nuesoft Ltd
>

Thanks for replying, and you may have hit on it.

We discovered that the original programmer had had several instances of the
VB IDE open during a 'debugging' session, with both the group and individual
projects open (and likely modified) at the same time. I am willing to bet
that in those situations - the oportunity for "undefined" behavior is very
high.

[James Barbetti]

Hi Ralph, Anthony.

I'm with anthony on the "binary compatibility setting" theory.
I've seen the same thing. It can also happen with "project compatibility".
Basically all you need is for someone to "branch" a VB project, working
on two different versions after *either* binary or project compatibility
has been set.

The (rather brutal) solution to the problem is to choose which of the
libraries is going to cop a CLSID change. Then edit its project so that
it has *no* compatibility set, unregister it, delete its DLL, and
build a new DLL. Then flip binary or project compatibility back on.
Well, solution is maybe too nice a word for it. If you've other
libraries with hard-typed references to classes from the DLL you do this
to, you've rather more work ahead of you!

I've accidentally done this to myself a couple of times over the last
two years. Don't ask me how, I don't know!

Seeya,
James