.Net Abstract base classes vs. interfaces

An interesting piece here from Phil Haack about why they decided to use an abstract base class rather than an interface.

Versioning is always a complicated thing for library designers. I know that I’m lucky in that I don’t have a gazillion users of my libraries so I tend to make breaking changes rather than build up technical debt in the name of backwards compatibility but I’ve worked on software where we couldn’t do that and where binary compatibility was important.

The fact that you can work around part of the .Net type versioning system by using abstract base classes is interesting but is just a hack. I haven’t investigated this in detail (or at all really ;) ) but it seems that Phil’s team’s fix solves the problem in an “Only Forward” kind of way. That is, they can add to an interface and provide a default implementation so if you upgrade to the newer library then your code still works. However, if you downgrade you’re screwed because you’re relying on stuff that doesn’t exist anymore. Of course this is a reasonable trade off. The alternative, of IDoThingEx or IDoThing2 interfaces isn’t great either and unless you continue to return instances of IDoThing and force users to cast to IDoThing2 then you end up chasing these kind of changes through the whole code base.