locked
Class Lib - Backward Compatibility RRS feed

  • Question

  • Hello,

     

    I've been working on a lib I'd like to publish.  I'm planning to maintain the lib in the future.

     

    Let's say someone writes an app using this lib and deploys to production on Day-X.  On Day-X+1 I make a bug fix and re-release the lib.  It would be really cool if they just take the new DLL and replace their old one (kind of like the COM days), and take advantage of the fix in thier app without recompiling.

     

    I think to do this, I need to make sure that I'm not breaking compatibility between the two version of the lib...is that right?

     

    I cann't find a guide on how to ensure backward compatibility, I looked through the book 'Framework Design Guideline', there are a few pointer in there such as: explicitily defining enum values so that when a new enum value is added, backward compatibility is maintained.

     

    Is there an existing guidline for writing code that is backward compatible?

     

    Thanks

    Sunday, April 8, 2007 1:54 AM

Answers

  • FxCop's "Breaking Change" means if you fix the FxCop warning you'll likely break code that uses what you're changing.  It doesn't apply to versioning of class libraries.

     

    What you're talking about is versioning.  You'll probably want to read some references like http://msdn2.microsoft.com/en-us/library/51ket42z(vs.80).aspx.

     

    In general, you should follow specific rules, some are covered by FxCop (i.e. naming of replacement or extension members with a "2" or "3" suffix rather than "Ex") and some aren't.  The basic axiom is "never change a published interface".  An interface is a contract, if you break that contract you break all clients of that contract.

     

    Generally, bug fixes aren't breaking changes though.  If you find a "fix" requires a design change that affects a contract you should deprecate the old contract (or a particular member of that contract) and introduce a replacement.

    Sunday, April 8, 2007 4:55 PM
    Moderator

All replies

  • One addition: FxCop does indicate breaking changes, but I'd like a more proactive source.

    Thanks

    Sunday, April 8, 2007 3:36 AM
  • FxCop's "Breaking Change" means if you fix the FxCop warning you'll likely break code that uses what you're changing.  It doesn't apply to versioning of class libraries.

     

    What you're talking about is versioning.  You'll probably want to read some references like http://msdn2.microsoft.com/en-us/library/51ket42z(vs.80).aspx.

     

    In general, you should follow specific rules, some are covered by FxCop (i.e. naming of replacement or extension members with a "2" or "3" suffix rather than "Ex") and some aren't.  The basic axiom is "never change a published interface".  An interface is a contract, if you break that contract you break all clients of that contract.

     

    Generally, bug fixes aren't breaking changes though.  If you find a "fix" requires a design change that affects a contract you should deprecate the old contract (or a particular member of that contract) and introduce a replacement.

    Sunday, April 8, 2007 4:55 PM
    Moderator