.NET and compatibility


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 9 of 9

Thread: .NET and compatibility

  1. #1
    Willy Van den Driessche Guest

    .NET and compatibility

    I've been programming for 4 years in VB and had to struggle hard to get a
    grip on binary compatibility. Now that I more or less understand it, I love
    it (if it works). It's a good way to warn me when I'm doing things that
    would break existing code.
    I've read Applemans book and saw that it is still possible to upgrade
    components - even past inheritance hierarchies. Not all architectures
    require or even survive side by side execution (I know mine which is a
    plugin-base thing doesn't). From what I know of it there will still be
    components that compare roughly to our good old COM components : only latest
    version available.

    Is there something that takes you by the hand to tell you when you're about
    to break existing code for shared components ? Or is it disciplined coding
    once again for these kinds of components ?
    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html



  2. #2
    Arthur Wood Guest

    Re: .NET and compatibility


    Willy,

    .NET does NOT use the registry, so there is no need for "Bianry Compatability"
    -- each assembly is complete self-contained, so that when you create a new
    version of a library, only the version of the app that actually uses THAT
    version of the library is involved. any other app, which might use another
    version of that same library is NOT affected in any way.

    That is how the .NET framework almost completely eliminates "DLL ****".

    Arthur Wood


    "Willy Van den Driessche" <Willy.Van.denDriessche@skynet.be> wrote:
    >I've been programming for 4 years in VB and had to struggle hard to get

    a
    >grip on binary compatibility. Now that I more or less understand it, I

    love
    >it (if it works). It's a good way to warn me when I'm doing things that
    >would break existing code.
    >I've read Applemans book and saw that it is still possible to upgrade
    >components - even past inheritance hierarchies. Not all architectures
    >require or even survive side by side execution (I know mine which is a
    >plugin-base thing doesn't). From what I know of it there will still be
    >components that compare roughly to our good old COM components : only latest
    >version available.
    >
    >Is there something that takes you by the hand to tell you when you're about
    >to break existing code for shared components ? Or is it disciplined coding
    >once again for these kinds of components ?
    >--
    >Van den Driessche Willy
    >For a work in progress :
    >http://users.skynet.be/wvdd2/index.html
    >
    >



  3. #3
    Willy Van den Driessche Guest

    Re: .NET and compatibility


    Arthur,
    thanks for responding.

    I'll explain my case a little better. I currently have an architecture in
    which I share state between DLLs by having a local state in certain DLLs
    (in english math : If DLL A and B both use dll C and a modifies a global
    variable in C then B will see that modif). This architecture implies that
    all DLL's have to be using exactly the same version of a referenced DLL.
    (In the example A would modify C1 and B would not see the change in C2).
    For this to work, the referenced DLL (C in the example) should be modified
    only in compatible ways. If I delete a class from that DLL, the new references
    can deal with it but the old ones will crash (gracefully) because they don't
    find it. I would thus like the tool to warn me when I make a new version
    that is not compatible with an older version. This compatibility need not
    be based on a typelib or something in the registry but can just as well be
    based one the metadata in the manifest.
    From your answer I deduce that if I want that, I'll need to write an addin
    myself. Since I presume I will not be the only one having this problem (hubris)
    I just want to know if they have built something for me already.

    See You and thanks again.
    Willy.


  4. #4
    Rob Teixeira Guest

    Re: .NET and compatibility


    "Willy Van den Driessche" <Willy.van.den.driessche@skynet.be> wrote:
    >
    >I'll explain my case a little better. I currently have an architecture

    in
    >which I share state between DLLs by having a local state in certain DLLs
    >(in english math : If DLL A and B both use dll C and a modifies a global
    >variable in C then B will see that modif).


    Note that this will not work cross-process in VB6. So if A and B were EXE's
    instead of DLL's, the global values in C would not be shared (obviously).
    In addition, if different threads are executing (even in the same process),
    the global values are stored in TLS, and the threads would see different
    values as well.

    >This architecture implies that
    >all DLL's have to be using exactly the same version of a referenced DLL.
    > (In the example A would modify C1 and B would not see the change in C2).
    >For this to work, the referenced DLL (C in the example) should be modified
    >only in compatible ways. If I delete a class from that DLL, the new references
    >can deal with it but the old ones will crash (gracefully) because they don't
    >find it.


    The truth is that an Interface, once published, should not change at all
    (never mind "in a compatible way"). VB6 actually does that. If you modify
    an interface and recompile, the old interface is maintained, a new one is
    generated, and you get interface forwarding. Needless to say, there are a
    lot of evil side-effects and bugs with keeping Binary Compatibility (try
    doing a search on Binary Compatibility to see what I mean).

    So, basically, the way to handle things is to maintain immutable interfaces.
    Once you push an interface into production, it should not change. This doesn't
    mean you can't fix bugs. You can change/fix the implementation of a class
    and still maintain an interface. If the interface needs to change, make a
    new interface, and allow the implementing class to implement both the old
    and new interfaces if appropriate. Old code continues to work and the new
    client code takes advantage of the new features.

    Having said that, I think you have two seperate issues here. One of them
    is this change of interface problem. The other is having two binaries (libraries/processes)
    see the same entities. For this second issue, I suggest reading up on Singleton
    classes in .NET.

    >I would thus like the tool to warn me when I make a new version
    >that is not compatible with an older version.


    This would be nice, but the ideal thing (to reiterate) is not to change a
    published interface.

    >This compatibility need not
    >be based on a typelib or something in the registry but can just as well

    be
    >based one the metadata in the manifest.


    It would have to be.

    >From your answer I deduce that if I want that, I'll need to write an addin
    >myself.
    >Since I presume I will not be the only one having this problem (hubris)
    >I just want to know if they have built something for me already.


    Well, as stated earlier in the thread, .NET's way of handling DLL **** is
    to maintain seperate versions of the DLL assemblies components. A project
    using version MyWidget v1.2 would continue to use 1.2 even when another project
    installs MyWidget v1.5.

    Your problem lies in a shared assembly component. I think you should look
    into some different strategies with the new tools, as opposed to looking
    for a way to not break compatibility when changing the exposed interface
    of a component (preferably avoiding doing that).

    -Rob

  5. #5
    Willy Van den Driessche Guest

    Re: .NET and compatibility

    Rob,

    thanks for replying. I must say that there a lot of VB6 compatibility
    things I know already. I've mostly discovered them through blood sweat
    tears and anger. I have even written an article about it at :
    http://users.skynet.be/wvdd2/General...compiling.html
    fro which the idea is to get Reponses whenever I say stupid things.

    > >
    > >I'll explain my case a little better. I currently have an architecture

    > in
    > >which I share state between DLLs by having a local state in certain DLLs
    > >(in english math : If DLL A and B both use dll C and a modifies a global
    > >variable in C then B will see that modif).

    >
    > Note that this will not work cross-process in VB6. So if A and B were

    EXE's
    > instead of DLL's, the global values in C would not be shared (obviously).
    > In addition, if different threads are executing (even in the same

    process),
    > the global values are stored in TLS, and the threads would see different
    > values as well.


    I know that. I've learned the threading issues the hard way. I was very
    glad I could circumvent the ROT singleton implementation, because our app
    has lots of them. (It's a main application with a large shared code base (6
    DLLs) and up to 26 plugins (DLLs)). [the alternative would have been a giant
    singleton but it would have broken encapsulation too much. I've considered
    a memento bag for this but didn't want to incur the performance penalty].
    Singlethreaded DLLs do their job just fine.

    >
    > >This architecture implies that
    > >all DLL's have to be using exactly the same version of a referenced DLL.
    > > (In the example A would modify C1 and B would not see the change in C2).
    > >For this to work, the referenced DLL (C in the example) should be

    modified
    > >only in compatible ways. If I delete a class from that DLL, the new

    references
    > >can deal with it but the old ones will crash (gracefully) because they

    don't
    > >find it.

    >
    > The truth is that an Interface, once published, should not change at all
    > (never mind "in a compatible way"). VB6 actually does that. If you modify
    > an interface and recompile, the old interface is maintained, a new one is
    > generated, and you get interface forwarding. Needless to say, there are a
    > lot of evil side-effects and bugs with keeping Binary Compatibility (try
    > doing a search on Binary Compatibility to see what I mean).


    I know. Still I find that once you 'get' binary compatibility it is a very
    nice thing. Apart from the OCA problems [IMHO problems I could never have
    solved myself] which Matthew Curland helped me with I haven't had any
    problems with binary compatibility any more. The rules are in fact simple.
    The problem is Microsoft doesn't document them anywhere the way it should.
    I'm halfway of having a build tool that works as outlined in my article (no
    compilation rippling - components only get compiled when the sources change
    / Assist in breaking compatibility by renaming the DLLs and changing the
    ProgIDs, CMP files handling, Time estimates for builds, ...)

    >
    > So, basically, the way to handle things is to maintain immutable

    interfaces.
    > Once you push an interface into production, it should not change. This

    doesn't
    > mean you can't fix bugs. You can change/fix the implementation of a class
    > and still maintain an interface. If the interface needs to change, make a
    > new interface, and allow the implementing class to implement both the old
    > and new interfaces if appropriate. Old code continues to work and the new
    > client code takes advantage of the new features.


    I know. [Dan appleman was so kind to point to other issues - which we
    experienced as well - that can break applications even if they are binary
    compatible. It has to do with implementation issues leaking out. It even
    means that it some cases you're not allowed to fix buggy (not crashy) code.]

    >
    > Having said that, I think you have two seperate issues here. One of them
    > is this change of interface problem. The other is having two binaries

    (libraries/processes)
    > see the same entities. For this second issue, I suggest reading up on

    Singleton
    > classes in .NET.


    I would really apreciate any reference on that.

    >
    > >I would thus like the tool to warn me when I make a new version
    > >that is not compatible with an older version.

    >
    > This would be nice, but the ideal thing (to reiterate) is not to change a
    > published interface.


    I think we both know that VB6 wouldn't have done so much work for us if we
    believed in that. VB6 does a good (alas not a perfect) job in guiding you
    towards a compatible implementation. Never changing an interface leads to
    code blur (much manually inherited interfaces and classes with factories to
    guide you).

    >
    > >From your answer I deduce that if I want that, I'll need to write an

    addin
    > >myself.
    > >Since I presume I will not be the only one having this problem (hubris)
    > >I just want to know if they have built something for me already.

    >
    > Well, as stated earlier in the thread, .NET's way of handling DLL **** is
    > to maintain seperate versions of the DLL assemblies components. A project
    > using version MyWidget v1.2 would continue to use 1.2 even when another

    project
    > installs MyWidget v1.5.


    As far as I understand it (I'm a NET newbie) you have the choice to wire the
    referenced component versions in you app or to use the latest installed
    version (within boundaries). [if this is wrong then I rest my case] However,
    and this is the point of the whole discussion, if the upgraded component is
    not 'compatible', I get a runtime error. It's not "activeX can't create
    object", but it's awfully similar. If I would have a tool assist me in
    upgrading my components, this would not occur. I've done COM programming in
    Delphi and C++ too. These tools force full responsibility for COM
    programming on your shoulder. I like the fact that VB6 looks in over my
    shoulder to tell me (and my collegues) that we're doing something wrong. I
    don't like to care about such things too much while I'm developing my
    component.
    Side by side component execution makes this less necessary but I still think
    it is very useful.

    >
    > Your problem lies in a shared assembly component. I think you should look
    > into some different strategies with the new tools, as opposed to looking
    > for a way to not break compatibility when changing the exposed interface
    > of a component (preferably avoiding doing that).


    I'm not sure, but I think the kind of application I'm dvelopping drives me
    to the GAC. If I understand it correctly, this is where .NET wants you to
    put compatible things.

    see you,
    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html



  6. #6
    Jonathan Allen Guest

    Re: .NET and compatibility

    > Note that this will not work cross-process in VB6. So if A and B were
    EXE's
    > instead of DLL's, the global values in C would not be shared (obviously).
    > In addition, if different threads are executing (even in the same

    process),
    > the global values are stored in TLS, and the threads would see different
    > values as well.



    TLS? What's that?

    --
    Jonathan Allen



    "Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    news:3bdefb0e$1@news.devx.com...
    >
    > "Willy Van den Driessche" <Willy.van.den.driessche@skynet.be> wrote:
    > >
    > >I'll explain my case a little better. I currently have an architecture

    > in
    > >which I share state between DLLs by having a local state in certain DLLs
    > >(in english math : If DLL A and B both use dll C and a modifies a global
    > >variable in C then B will see that modif).

    >
    > Note that this will not work cross-process in VB6. So if A and B were

    EXE's
    > instead of DLL's, the global values in C would not be shared (obviously).
    > In addition, if different threads are executing (even in the same

    process),
    > the global values are stored in TLS, and the threads would see different
    > values as well.
    >
    > >This architecture implies that
    > >all DLL's have to be using exactly the same version of a referenced DLL.
    > > (In the example A would modify C1 and B would not see the change in C2).
    > >For this to work, the referenced DLL (C in the example) should be

    modified
    > >only in compatible ways. If I delete a class from that DLL, the new

    references
    > >can deal with it but the old ones will crash (gracefully) because they

    don't
    > >find it.

    >
    > The truth is that an Interface, once published, should not change at all
    > (never mind "in a compatible way"). VB6 actually does that. If you modify
    > an interface and recompile, the old interface is maintained, a new one is
    > generated, and you get interface forwarding. Needless to say, there are a
    > lot of evil side-effects and bugs with keeping Binary Compatibility (try
    > doing a search on Binary Compatibility to see what I mean).
    >
    > So, basically, the way to handle things is to maintain immutable

    interfaces.
    > Once you push an interface into production, it should not change. This

    doesn't
    > mean you can't fix bugs. You can change/fix the implementation of a class
    > and still maintain an interface. If the interface needs to change, make a
    > new interface, and allow the implementing class to implement both the old
    > and new interfaces if appropriate. Old code continues to work and the new
    > client code takes advantage of the new features.
    >
    > Having said that, I think you have two seperate issues here. One of them
    > is this change of interface problem. The other is having two binaries

    (libraries/processes)
    > see the same entities. For this second issue, I suggest reading up on

    Singleton
    > classes in .NET.
    >
    > >I would thus like the tool to warn me when I make a new version
    > >that is not compatible with an older version.

    >
    > This would be nice, but the ideal thing (to reiterate) is not to change a
    > published interface.
    >
    > >This compatibility need not
    > >be based on a typelib or something in the registry but can just as well

    > be
    > >based one the metadata in the manifest.

    >
    > It would have to be.
    >
    > >From your answer I deduce that if I want that, I'll need to write an

    addin
    > >myself.
    > >Since I presume I will not be the only one having this problem (hubris)
    > >I just want to know if they have built something for me already.

    >
    > Well, as stated earlier in the thread, .NET's way of handling DLL **** is
    > to maintain seperate versions of the DLL assemblies components. A project
    > using version MyWidget v1.2 would continue to use 1.2 even when another

    project
    > installs MyWidget v1.5.
    >
    > Your problem lies in a shared assembly component. I think you should look
    > into some different strategies with the new tools, as opposed to looking
    > for a way to not break compatibility when changing the exposed interface
    > of a component (preferably avoiding doing that).
    >
    > -Rob



  7. #7
    Phil Weber Guest

    Re: .NET and compatibility

    > TLS? What's that?

    Jonathan: Thread Local Storage
    ---
    Phil Weber



  8. #8
    Rob Teixeira Guest

    Re: .NET and compatibility


    "Willy Van den Driessche" <Willy.Van.denDriessche@skynet.be> wrote:
    >Rob,
    >
    >thanks for replying. I must say that there a lot of VB6 compatibility
    >things I know already. I've mostly discovered them through blood sweat
    >tears and anger.


    Yeah, that's the way most of us found them too

    >I know. Still I find that once you 'get' binary compatibility it is a very
    >nice thing.


    I think the "nice" thing about binary compatibility, which i believe is also
    what you like about it, is the way the VB6 compiler interprets compatibility
    and warns you of any incompatibilities.
    That part I wouldn't mind having in VB.NET. The implementation of Binary
    compatibility, on the other hand, leaves a lot to be desired and is far too
    tied into COM implementation and type library information.

    This is why I'm in favor of defining strict and distinct interfaces, then
    implementing those interfaces in your classes (much the same way you deal
    with COM in C++). A change in interface would then physically require a second
    new interface. The class itself can implement both the old and new interfaces.

    >The problem is Microsoft doesn't document them anywhere the way it should.


    I agree

    >I know. [Dan appleman was so kind to point to other issues - which we
    >experienced as well - that can break applications even if they are binary
    >compatible. It has to do with implementation issues leaking out. It even
    >means that it some cases you're not allowed to fix buggy (not crashy) code.]


    Exactly. I just ran into one of those problems last week while maintaining
    some VB6 code. I won't miss VB6 binary compatibility once it goes away, that's
    for sure. Worse yet, this problem didn't allow a compile even though it should
    have.

    >I would really apreciate any reference on that.


    http://msdn.microsoft.com/library/de...ed_objects.asp

    http://msdn.microsoft.com/library/de...atsingserv.asp

    http://msdn.microsoft.com/library/de...roremoting.asp

    Just to get you started. Once you understand some of the high-level concepts
    in these articles, you should be able to dig into the framework class library
    SDK docs for the rest.

    >I think we both know that VB6 wouldn't have done so much work for us if

    we
    >believed in that.


    Well, there were other reasons for VB6 to do this as well. One of the major
    reasons was that VB6 blurred the lines between what was an interface and
    what was a class. Another reason was that with COM, you have no choice -
    once you set an interface in motion, it is set in stone.

    >VB6 does a good (alas not a perfect) job in guiding you
    >towards a compatible implementation.


    And this "warning" aspect of the feature is what I'd like to see VB.NET,
    but only cases where people attempt to change their published interfaces
    will it be a useful tool at that. Personally, I'd rather avoid that situation
    in the first place.

    >Never changing an interface leads to
    >code blur (much manually inherited interfaces and classes with factories

    to
    >guide you).


    Well, that depends on the architecture, scope, and a hundred other things.
    I think that once you get passed a certain point and you find that you have
    a radical number of changes, it's probably worth going back to drawing board.
    Plus, I believe that at that point binary compatibility won't help much anyway.

    >As far as I understand it (I'm a NET newbie) you have the choice to wire

    the
    >referenced component versions in you app or to use the latest installed
    >version (within boundaries). [if this is wrong then I rest my case]


    You do have a certain amount of control, yes.

    >However,
    >and this is the point of the whole discussion, if the upgraded component

    is
    >not 'compatible', I get a runtime error. It's not "activeX can't create
    >object", but it's awfully similar. If I would have a tool assist me in
    >upgrading my components, this would not occur. I've done COM programming

    in
    >Delphi and C++ too. These tools force full responsibility for COM
    >programming on your shoulder. I like the fact that VB6 looks in over my
    >shoulder to tell me (and my collegues) that we're doing something wrong.



    True enough, but this isn't COM anymore
    Still, I'll say again that I'd like a warning tool, in the rare instance
    that I might want to change a published interface. I'm not arguing with that.

    >I don't like to care about such things too much while I'm developing my
    >component.
    >Side by side component execution makes this less necessary but I still think
    >it is very useful.
    >
    >I'm not sure, but I think the kind of application I'm dvelopping drives

    me
    >to the GAC. If I understand it correctly, this is where .NET wants you

    to
    >put compatible things.


    This is where you put "Shared" components, which is not necessarily the same
    as "Compatible" components. You can after all, have several side-by-side
    versions of the same component (not all compatible) in the GAC as well.

    Hope that helps,
    -Rob

  9. #9
    Willy Van den Driessche Guest

    Re: .NET and compatibility

    Thanks for replying Rob. I'll have a look at the links you provided.

    We sort of agree that it would be handy to have an eye over the shoulder to
    warn us when we do things we shouldn't. AFAIK, VB6 achieves this by
    "comparing" typelibraries. If I'm not mistaken, the closest thing to
    typelibraries in .NET are assembly manifests.

    Problem 1 would be that you need to generate a manifest from the code
    because in theory the warning should come before the thing gets broken. In
    practice we can ignore this because nothing is lost if we warn just after a
    compile. That way we can use the manifest .NET generated for us.

    Problem 2 would be that it is difficult to define compatibility. I've done
    an attempt for VB6 at :
    http://users.skynet.be/wvdd2/General...iling.html#Whi
    chChangesAreCompatible
    The list is not complete but it covers the most common problems.
    ..NET compatibility is an order of magnitude more complex :
    Interfaces as well as class provide inheritance. Inheritance adds to the
    interface of a class.
    Attributes allow 'code coloring'. Some attributes are irrelevant, others
    are highly relevant.

    If I can find the time I would like to have a go at composing a list. I
    could even build the tool. Apparently the manifest is completely accessible
    through code. From what I've seen making an addin out of this is just as
    easy as it was in VB6.

    See you.
    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html




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