Home/ Questions/Q 6560199
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T13:25:45+00:00

I would like to detect breaking changes in .NET code (specifically C#) whenever TFS

  • 0

I would like to detect breaking changes in .NET code (specifically C#) whenever TFS builds a solution. If there are any breaking changes (such as outlined in “A definite guide to API-breaking changes in .NET“) between the code being checked in and the version in the most recent successful build, I would like to know about it. A breaking change needn’t cause the build to fail. Short of writing an app that uses reflection to compare two versions of the same assembly, how can this be done?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    1. Changing the version of a referenced DLL should be considered a breaking change.
    2. removing/changing members breaks backwards compatibility.
    3. adding members breaks forwards compatibility (some people just consider ‘added members’ as safe, but it does have a risk associated).
    4. Change file version with every build, you will need it at some point.
    5. 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.
    6. Dont forget about Attributes, changes to them may not break static compatiblity, but could affect the runtime.
    • 0