Why is this not binary compatible


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 3 of 3

Thread: Why is this not binary compatible

  1. #1
    Kip Fryman Guest

    Why is this not binary compatible


    Original definition:
    Sub ModifyQueueSchedule(Sched As ttaxsrv.CScheduleItem)

    Current definition:
    Sub ModifyQueueSchedule(Sched As CScheduleItem)

    Is this a bug in VB. It is the same reference except it is not prefixed
    with the project name. It is not compatible vice versa.

    Can someone explain why?


    Below is a little history of the problem-

    ----------------------------
    Then I must agree with you that the thing should be binary compatible. I
    suggest you repost your thing in the vb.control.creation.dcom or vb.oop
    newsgroup at www.devx.com. Matthew Currland attends that quite often and
    he
    is an absolute expert in binary compatibility. Hope for you that he's
    @home.

    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html
    "Kip Fryman" <kip@NOSPAM.com> wrote in message
    news:#AcL3wgNBHA.1312@tkmsftngp05...
    > I guarentee I don't have two CScheduleItem classes in different libraries
    >
    > "Willy Van den Driessche" <Willy.Van.denDriessche@skynet.be> wrote in
    > message news:#MaiuwcNBHA.1840@tkmsftngp05...
    > > Just an idea.
    > > Are you sure CScheduleItem is ONLY in the ttaxsrv library ? If it is

    also
    > in
    > > another library then VB makes sense. If you remove the explicit type

    > (with
    > > ttaxsvr.) then it will first search in the current library and next the
    > > order of the references is determiniming what your type will be.
    > >
    > > --
    > > Van den Driessche Willy
    > > For a work in progress :
    > > http://users.skynet.be/wvdd2/index.html
    > > "Kip Fryman" <kip@NOSPAM.com> wrote in message
    > > news:uH4HIjbNBHA.1476@tkmsftngp03...
    > > > Nothing had been changed in the ttaxsrv component at all. The only

    > thing
    > > > changed was in the client program calling it.
    > > >
    > > > Changed from ttaxsrv.CScheduleItem to just CScheduleItem.
    > > >
    > > >
    > > >
    > > >
    > > > "Paul Overway" <paul@no-spam.logico-solutions.com> wrote in message
    > > > news:OxHYVgaNBHA.2124@tkmsftngp05...
    > > > > Matt:
    > > > >
    > > > > You've explained this very well....and I'm following what might have
    > > > > happened now. I hadn't picked up on the dependency aspect of this.
    > > > >
    > > > > It may be that nothing changed at all in respect to the

    CScheduleItem
    > > > object
    > > > > Kip was referencing, but because compatibility was broken by

    changing
    > > > > another object in that library, it broke compatibility for all.

    For
    > > > > example, if CTaskItem is in the same library and a property was

    > removed
    > > > from
    > > > > it. The developer of the ttaxsrv library would have been warned

    that
    > > > binary
    > > > > compatibility was being broken, but because this warning was

    ignored,
    > > now
    > > > > Kip's library is broke...and so on and so on. All must suffer

    > because
    > > > the
    > > > > ttaxsrv developer didn't understand what happens when compatibility

    is
    > > > > broken.
    > > > >
    > > > > --
    > > > > Paul Overway, MCSD
    > > > > Logico Solutions, LLC
    > > > >
    > > > >
    > > > >
    > > > > "Matthew Solnit" <msolnit@nospam.yahoo-com> wrote in message
    > > > > news:ePyiRBaNBHA.864@tkmsftngp05...
    > > > > > "Paul Overway" <paul@no-spam.logico-solutions.com> wrote in

    message
    > > > > > news:eicrdVYNBHA.1672@tkmsftngp03...
    > > > > > > Kip:
    > > > > > >
    > > > > > > You have changed the data type for the arguement. For all VB

    > knows,
    > > > you
    > > > > are
    > > > > > > referring to a completely different data type. And that's all

    it
    > > > takes
    > > > > to
    > > > > > > break compatbility.
    > > > > >
    > > > > > On the contrary, I believe it is the same data type. Why?

    Because
    > > I'm
    > > > > almost
    > > > > > 100% positive that the VB compiler doesn't actually see the text
    > > > > > "CScheduleItem", which has changed to "ttaxsrv.CScheduleItem".

    > > Instead,
    > > > > I'm
    > > > > > betting it turns this into a CLSID (class ID) or even an IID

    > > (interface
    > > > > ID),
    > > > > > which does +not+ change when you add the library name in front

    of
    > the
    > > > > class
    > > > > > name.
    > > > > >
    > > > > > Here is a little experiment which seems to prove my hypothesis.

    Try
    > > > > creating a
    > > > > > dummy class, with a dummy method that accepts an ADO Recordset

    as
    a
    > > > > parameter.
    > > > > > If you change the code from "As Recordset" to "As ADODB.Recordset"

    > you
    > > > > will see
    > > > > > that VB is fine with this change, i.e. binary compatibility is

    +not+
    > > > being
    > > > > > broken.
    > > > > >
    > > > > > However, if binary compatibility has been broken for the +ttaxsrv+
    > > > library
    > > > > (the
    > > > > > dependency), then the CLSID has changed, and so binary

    compatibility
    > > is
    > > > > broken
    > > > > > for your class as well, because the data type really has changed

    for
    > > the
    > > > > > parameter.
    > > > > >
    > > > > > Going back to our sample project, try changing the reference from

    > ADO
    > > > 2.5
    > > > > to ADO
    > > > > > 2.0. You will see that even though the code is unchanged, binary
    > > > > compatibility
    > > > > > has been broken, because the CLSID of the Recordset class has

    > changed.
    > > > > >
    > > > > > Hope this helps,
    > > > > > Matthew Solnit
    > > > > >
    > > > > >
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >




  2. #2
    Jay Guest

    Re: Why is this not binary compatible


    Kip,

    Not sure if this will help, but it sounds like a problem I was having with
    one of interfaces. I had a interface defined in VB, and one of the methods
    took a custom object as an argument. eg. Sub TestProc(TheObject as Custom.Object)
    The custom object did not implement a custom interface, it just exposed
    the default interface VB builds when you compile a normal DLL. This interface
    was implemented in a lot objects I was using. Anyways, turns out, I had
    to add a new method to Custom.Object. So I added the method, compiled it,
    and didn't think anything of it.

    Problem is, VB generated a new public interface for Custom.Object, and my
    interface was dependent on the previous interface definition. So anytime
    I went to compile an object that implemented my custom interface, I kept
    on getting binary compatibility errors. If your problem is similar, open
    your object in OLE Viewier. Check to see if there are multiple declarations
    of the public interface in your object. If there are, it probably means
    the method in question is bound to the old interface. You can specify a
    specific interface to use when declaring arguments for a procedure. For
    example, if you're using ADO 2.0, and you want your procedure to use the
    2.0 recordset interface regardless if you upgrade to 2.7, you can declare
    the recordset as Recordset20. I believe that's the right syntax for that
    interface, but don't quote me on that. Anyways, hope this helps.

    Jay

    "Kip Fryman" <kip@nospam.com> wrote:
    >
    >Original definition:
    > Sub ModifyQueueSchedule(Sched As ttaxsrv.CScheduleItem)
    >
    >Current definition:
    > Sub ModifyQueueSchedule(Sched As CScheduleItem)
    >
    >Is this a bug in VB. It is the same reference except it is not prefixed
    >with the project name. It is not compatible vice versa.
    >
    >Can someone explain why?
    >
    >
    >Below is a little history of the problem-
    >
    >----------------------------
    >Then I must agree with you that the thing should be binary compatible.

    I
    >suggest you repost your thing in the vb.control.creation.dcom or vb.oop
    >newsgroup at www.devx.com. Matthew Currland attends that quite often and
    >he
    >is an absolute expert in binary compatibility. Hope for you that he's
    >@home.
    >
    >--
    >Van den Driessche Willy
    >For a work in progress :
    >http://users.skynet.be/wvdd2/index.html
    >"Kip Fryman" <kip@NOSPAM.com> wrote in message
    >news:#AcL3wgNBHA.1312@tkmsftngp05...
    >> I guarentee I don't have two CScheduleItem classes in different libraries
    >>
    >> "Willy Van den Driessche" <Willy.Van.denDriessche@skynet.be> wrote in
    >> message news:#MaiuwcNBHA.1840@tkmsftngp05...
    >> > Just an idea.
    >> > Are you sure CScheduleItem is ONLY in the ttaxsrv library ? If it is

    >also
    >> in
    >> > another library then VB makes sense. If you remove the explicit type

    >> (with
    >> > ttaxsvr.) then it will first search in the current library and next

    the
    >> > order of the references is determiniming what your type will be.
    >> >
    >> > --
    >> > Van den Driessche Willy
    >> > For a work in progress :
    >> > http://users.skynet.be/wvdd2/index.html
    >> > "Kip Fryman" <kip@NOSPAM.com> wrote in message
    >> > news:uH4HIjbNBHA.1476@tkmsftngp03...
    >> > > Nothing had been changed in the ttaxsrv component at all. The only

    >> thing
    >> > > changed was in the client program calling it.
    >> > >
    >> > > Changed from ttaxsrv.CScheduleItem to just CScheduleItem.
    >> > >
    >> > >
    >> > >
    >> > >
    >> > > "Paul Overway" <paul@no-spam.logico-solutions.com> wrote in message
    >> > > news:OxHYVgaNBHA.2124@tkmsftngp05...
    >> > > > Matt:
    >> > > >
    >> > > > You've explained this very well....and I'm following what might

    have
    >> > > > happened now. I hadn't picked up on the dependency aspect of this.
    >> > > >
    >> > > > It may be that nothing changed at all in respect to the

    >CScheduleItem
    >> > > object
    >> > > > Kip was referencing, but because compatibility was broken by

    >changing
    >> > > > another object in that library, it broke compatibility for all.

    >For
    >> > > > example, if CTaskItem is in the same library and a property was

    >> removed
    >> > > from
    >> > > > it. The developer of the ttaxsrv library would have been warned

    >that
    >> > > binary
    >> > > > compatibility was being broken, but because this warning was

    >ignored,
    >> > now
    >> > > > Kip's library is broke...and so on and so on. All must suffer

    >> because
    >> > > the
    >> > > > ttaxsrv developer didn't understand what happens when compatibility

    >is
    >> > > > broken.
    >> > > >
    >> > > > --
    >> > > > Paul Overway, MCSD
    >> > > > Logico Solutions, LLC
    >> > > >
    >> > > >
    >> > > >
    >> > > > "Matthew Solnit" <msolnit@nospam.yahoo-com> wrote in message
    >> > > > news:ePyiRBaNBHA.864@tkmsftngp05...
    >> > > > > "Paul Overway" <paul@no-spam.logico-solutions.com> wrote in

    >message
    >> > > > > news:eicrdVYNBHA.1672@tkmsftngp03...
    >> > > > > > Kip:
    >> > > > > >
    >> > > > > > You have changed the data type for the arguement. For all VB

    >> knows,
    >> > > you
    >> > > > are
    >> > > > > > referring to a completely different data type. And that's all

    >it
    >> > > takes
    >> > > > to
    >> > > > > > break compatbility.
    >> > > > >
    >> > > > > On the contrary, I believe it is the same data type. Why?

    >Because
    >> > I'm
    >> > > > almost
    >> > > > > 100% positive that the VB compiler doesn't actually see the text
    >> > > > > "CScheduleItem", which has changed to "ttaxsrv.CScheduleItem".
    >> > Instead,
    >> > > > I'm
    >> > > > > betting it turns this into a CLSID (class ID) or even an IID
    >> > (interface
    >> > > > ID),
    >> > > > > which does +not+ change when you add the library name in front

    >of
    >> the
    >> > > > class
    >> > > > > name.
    >> > > > >
    >> > > > > Here is a little experiment which seems to prove my hypothesis.

    >Try
    >> > > > creating a
    >> > > > > dummy class, with a dummy method that accepts an ADO Recordset

    >as
    >a
    >> > > > parameter.
    >> > > > > If you change the code from "As Recordset" to "As ADODB.Recordset"

    >> you
    >> > > > will see
    >> > > > > that VB is fine with this change, i.e. binary compatibility is

    >+not+
    >> > > being
    >> > > > > broken.
    >> > > > >
    >> > > > > However, if binary compatibility has been broken for the +ttaxsrv+
    >> > > library
    >> > > > (the
    >> > > > > dependency), then the CLSID has changed, and so binary

    >compatibility
    >> > is
    >> > > > broken
    >> > > > > for your class as well, because the data type really has changed

    >for
    >> > the
    >> > > > > parameter.
    >> > > > >
    >> > > > > Going back to our sample project, try changing the reference from

    >> ADO
    >> > > 2.5
    >> > > > to ADO
    >> > > > > 2.0. You will see that even though the code is unchanged, binary
    >> > > > compatibility
    >> > > > > has been broken, because the CLSID of the Recordset class has

    >> changed.
    >> > > > >
    >> > > > > Hope this helps,
    >> > > > > Matthew Solnit
    >> > > > >
    >> > > > >
    >> > > >
    >> > > >
    >> > >
    >> > >
    >> >
    >> >

    >>
    >>

    >
    >



  3. #3
    Willy Van den Driessche Guest

    Re: Why is this not binary compatible


    Kip,
    To be able to answer you question, I created two little DLLs. The first
    DLL1 contains a public class class1 with one public method Method1. It is
    compiled with binary compatibility.
    The second DLL2 contains a public class class2 with one public method Method2(byval
    anObject as DLL1.class1). It is also compiled with binary compatibility.

    When I changed
    Method2(byval anObject as DLL1.class1)
    to
    Method2(byval anObject as class1)
    there were no complaints at all.

    So I changed class1 and added method1Bis and recompiled.

    I opened server2 and recompiled without any complaints. (with explicit reference
    DLL1.class1 and then without the explicit reference)

    This means that I have a very difficult time helping you out, since I cannot
    reproduce the problem.

    Sorry,
    Willy.



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center