Re: COM component DLL producing different *.IDL file on different PCs.
- From: "Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 2 Dec 2005 18:49:48 -0000
I'm still a little confused Gem. Is your DLL physically copied between the 2
machines (i.e. it really is the same file), or is it rebuilt with binary
compatibility on each of the 2 machines?
I ask because although you do say "the file has not changed", you also talk
about the DLL apparently being adulterated by something, and so breaking
binary compatibility. The IDL viewer doesn't change the DLL though. Also, a
difference in the IDL output doesn't necessarily indicate a difference in
the DLL. The case of the stdole filename, for instance, depends on how it
was recorded in the 2 registries, not on some difference in the DLL. The
GUID for stdole.tlb will be the same.
If, on the other hand, the DLL is built on both machines then it gets a bit
more complicated. Binary compatibility only ensures the GUIDs are all the
same. We're currently investigating a problem ourselves where the exact same
project, built with exactly the same release of VB6, but on 2 different
machines, behaves very differently when installed on the same target
machine. One won't even register whilst the other is fine. This seems to be
a difference in the way one particular typedef is handled, and is pointing
the finger at a difference in OLE32.DLL on the 2 machines.
Tony Proctor
"Gemma M" <gemmamakepiece@xxxxxxxxxxx> wrote in message
news:dmq0sv$ae4$1$8302bc10@xxxxxxxxxxxxxxxxxxx
> Thanks for your contribution.
>
> The file in question HAS NOT CHANGED. It is built in VB using VB Binary
> Compatible rules. However, it produces different IDL output in COM/OLE
> viewer on different machines (namely the CUSTOM attribute on the library
and
> the case of the reference to stdole2.tlb/STDOLE2.TLB). The anomaly in the
> IDL output from COM/OLE Viewer is a symptom of the problem. On the
machine
> with the corruption, the COM component appears to be compatible, but on
the
> machines without the corruption, compatibility is broken in certain
> circumstances. All DLLs are exactly the same files in this compatibility
> chain, only the machines on which they run are different. The Binary
> compatibility fracture is another symptom.
>
> Note, that neither the GUID in the custom attribute, or the value 9782
> associated therewith, appear anywhere in my registry.
>
> I also assume it is a registry corruption on the one machine that behaves
> differently from all the others. What I am trying to solicit with my
> posting is how I am to discover what this corruption is. I am at the
point
> where I am considering re-building the machine in question (a drastic
step -
> hence my need to discover the problem, to prevent it occurring again).
>
> No description of the rules of Binary Compatibility ever touch on the
> fractures caused thereto by corruption in registry entries, corruptions
that
> RegClean (and others of its ilk, do not fix).
>
> Regards
> Gem
>
> "Ken Halter" <Ken_Halter@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:uh$0CS29FHA.1288@xxxxxxxxxxxxxxxxxxxxxxx
> > "Gemma M" <gemmamakepiece@xxxxxxxxxxx> wrote in message
> > news:dmpt03$dup$1$8300dec7@xxxxxxxxxxxxxxxxxxx
> >> Sorry, slight error. The custom(guid, 9782) is applied to the library
> >> itself, not the helpcontext. But, whatever it is, and wherever it
comes
> >> from, it is corrupting the cursed BINARY COMPATIBILITY (over which I
have
> >> no control, thanks to VB).
> >>
> >> Gem
> >
> > fwiw, I've never messed with IDL (or the OLE/COM Object Viewer) so I
have
> > no clue what may be causing the problem. Binary Compatibility though, is
> > no great mystery. Either the component's broken, or it's not. As long as
> > the compatibility model contains all publics, the DLL should be
> > compatible. If the model is missing a procedure, property, anything
> > Public, each time you compile, VB's generating new IIDs for that
> > interface. So, that component is broken. It just doesn't know it yet.
> > It'll work fine until the next compile. That's when things get
interesting
> > for clients that need the component.
> >
> > Since there's no rebuild between the steps you're talking about, Binary
> > Compatibility wouldn't be the problem. Maybe there's some registry
> > corruption going on somewhere.
> >
> > INFO: Registry Entries Made by an ActiveX Component
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;183771
> >
> > --
> > Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
> > DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
> > Freeware 4 color Gradient Frame? http://www.vbsight.com/GradFrameCTL.htm
> >
>
>
.
- Follow-Ups:
- References:
- COM component DLL producing different *.IDL file on different PCs.
- From: Gemma M
- Re: COM component DLL producing different *.IDL file on different PCs.
- From: Gemma M
- Re: COM component DLL producing different *.IDL file on different PCs.
- From: Ken Halter
- Re: COM component DLL producing different *.IDL file on different PCs.
- From: Gemma M
- COM component DLL producing different *.IDL file on different PCs.
- Prev by Date: Re: COM component DLL producing different *.IDL file on different PCs.
- Next by Date: Re: COM component DLL producing different *.IDL file on different PCs.
- Previous by thread: Re: COM component DLL producing different *.IDL file on different PCs.
- Next by thread: Re: COM component DLL producing different *.IDL file on different PCs.
- Index(es):
Relevant Pages
|
Loading
