Re: COM component DLL producing different *.IDL file on different PCs.

Hi,

The file is physically the same file, copied from one machine to the other.

I realise that producing IDL output using OLE/COM Viewer doesn't change the
DLL. What perplexes me most is that the output from OLE/COM Viewer (and the
IDL export mechanism of VC++) reports differently for the same physical
file, which points to an environment difference on the machines. And it
seems to me that whatever is causing this difference is causing the
difference in behaviour w.r.t. binary compatibility.

I agree that if the DLLs were built on different machines, then it would be
whole different ball game.

Thanks
Gem


"Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:e7EOtE39FHA.2936@xxxxxxxxxxxxxxxxxxxxxxx
> 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
>> >
>>
>>
>
>


.

Relevant Pages

  • Re: Binary Compatibility problem
    ... > a registered component can muck things up. ... Create copies of all of my latest DLL files and name _MyDLLx.dll ... Now Im not too sure of procedure for ensuring backward compatibility of any ... seamlessly in place of v1.0.0.0 on my users machines? ...
    (microsoft.public.vb.general.discussion)
  • Re: ASP.NET and NTidy
    ... We ran into the same issues using NTidy...the DLL would work fine on ... > I have 2 machines where my application runs without any problems but on my ... Attempting download of new URL ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: COM component DLL producing different *.IDL file on different PCs.
    ... Is your DLL physically copied between the 2 ... machines, or is it rebuilt with binary ... compatibility on each of the 2 machines? ... Binary compatibility only ensures the GUIDs are all the ...
    (microsoft.public.vb.com)
  • Re: Webservice stub class not compiling
    ... I cannot edit that DLL and the code you ... The code works fine on other people's machines ... > - it happens only when CSC is run from an ASPX page ... > The basic problem seems to be that csc does not tolerate this syntax. ...
    (microsoft.public.dotnet.framework.webservices)
  • Re: Win2k3 SP1 error: New transaction cannot enlist in the specifi
    ... This dll supports transactions, but does not initiate transaction calls. ... > It worked in both directions on both machines for DTC and RPC. ... >> Let's start changing the registry value for NetworkDTCAccess. ...
    (microsoft.public.windows.server.general)
Loading