Why is this not binary compatible

[Kip Fryman]

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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

[Jay]

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
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>

[Willy Van den Driessche]

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.