Yes, I would (and do) use NDepend for this.
I work on a product which provides an extendable API for developers. As such we need to make sure that between releases, we do not remove functionality that those developers may depend on.
The flip-side, is that we need the flexibility to grow the product without massive constraints around reversioning.
Some things you will want to consider.
- Changing the version of a referenced DLL should be considered a breaking change.
- removing/changing members breaks backwards compatibility.
- adding members breaks forwards compatibility (some people just consider 'added members' as safe, but it does have a risk associated).
- Change file version with every build, you will need it at some point.
- Consider writing contracts that define your 'public API'. These will be the members that you need to support outside of the organisation. Think of them as interoperability boundaries. It then allows your implementation classes to have public members, which arent in the API (hence considered 'unsupported'), so you can change them without worrying about breaking the extensibility API. Extending the API consists of writing a new interface (with a version number in the interface name) which DOES NOT derive from the prior version of interface (derivation prevents you from fully deprecating members, and creates hell when it comes time to implement multiple interface versions in a single class.
- Dont forget about Attributes, changes to them may not break static compatiblity, but could affect the runtime.
answered 2011-09-12T05:19:28.570