Checking for backwards compatibility

Hi,

is there any implementation of "backwards compatibility checks" already done using fxCop ?

the Context

Current Situation

We have a large VB6 application using 100+ inhouse developped DLLs and OCXes. This project is about to migrated to dotNet 2.0. There are several developpers on the team, not all as aware of backward compatibility problems. Up until now, we have used the "binary compatibility" feature in VB6 to check that version N+1 of a component is backwards compatible with version N of that same component. This feature allows any developer to make code changes and compile a new version of any component. Thanks to the "binary compatibility checker", the developer will know if he has made any changes that break the compatibility of the component. He can then check more thouroughly and "unbreak the changes", or ask an architect to "confirm the breaks".

The benefits

Having this automated knowledge helps us to update the application. Only projects in which sources have been modified will be recompiled (therefore not all dependent components have to be recompiled once a base component gets recompiled) and only changed components will be updated using our home brewn AutoUpdate feature. (which will actually download only the delta between the installed version and the latest version of a component - we also keep track of the versions of "referenced" components our component was compiled against). This allows for a download size to drop from higher than 40Mb to drop to less than 1 Mb (largely depending on how much the client is out of sync with the latest version). (Our application is still compatible with the version of 7 years ago - meaning plugins developped 7 years ago will still work unmodified in the current application)

I am aware that binary compatibility checks are only "syntactic" checks. They only guarantee that the calls will be possible. They don't guarantee anything at all concerning "semantic" compatibilty (it is not because method DoIt still takes 3 parameters that it still odes something semantically related). But syntactic compatibility is far better than no compatibility at all.

The desire

dotNet inverts the dll hell problem by default, which is - in general - AGT (a Good Thing). However, we would still like to be able to update only the changed components and not everything. IMHO this means we need some kind of "compatibility model". I don't want runtime checks to fail when a component was inadvertently changed in an incompatible way - I want it to be a compile time check. (I think the FxCop team agrees on this - if not there would be no need for fxCop)

Based on the backwards compatibility guarantee, I can then automate the process of generating publisher policy assemblies etc... Manually maintaining 100+ components and all of their interrelations is not something to be done manually.

The question

Does anybody know about efforts being done in this area. Is there already somebody who did it so that I don't have to rewrite it ?

The tool should "compare" version N+1 to version N of a component and establish a partial order ">=" so that it establishes version N+1 >= version N.

I have alreayd started this effort, only to notice that this is not documented at all. There is no documentation to help you to see if class A (version N +1) is still compatible with a previous version.

it never hurts to ask.

Willy.

[3790 byte] By [VandenDriesscheWilly] at [2007-12-28]