Sí, usaría (y lo haré) NDepend para esto. Trabajo en un producto que proporciona una API extensible para desarrolladores. Como tal, debemos asegurarnos de que, entre lanzamientos, no eliminemos la funcionalidad de la que pueden depender esos desarrolladores. El otro lado, es que necesitamos la flexibilidad para hacer crecer el producto sin restricciones masivas en torno a la reversión.
Algunas cosas que querrás considerar.
- Cambiar la versión de una DLL a la que se hace referencia se debe considerar un cambio de última hora.
- eliminar/cambiar miembros rompe la compatibilidad con versiones anteriores.
- añadiendo miembros se rompe la compatibilidad con versiones anteriores (algunas personas simplemente consideran "miembros agregados" como seguros, pero tiene un riesgo asociado).
- Cambie la versión del archivo con cada compilación, la necesitará en algún momento.
- Considera escribir contratos que definan tu 'API pública'. Estos serán los miembros que necesita para apoyar fuera de la organización. Piense en ellos como límites de interoperabilidad. A continuación, permite que sus clases de implementación tengan miembros públicos, que no están en la API (por lo tanto, se consideran 'no compatibles'), por lo que puede cambiarlos sin preocuparse por romper la API de extensibilidad. La extensión de la API consiste en escribir una nueva interfaz (con un número de versión en el nombre de la interfaz) que NO deriva de la versión anterior de la interfaz (la derivación evita que desaprobe por completo a los miembros y crea un infierno cuando llega el momento de implementar múltiples versiones de interfaz en una sola clase.
- no se olvide acerca de los atributos, cambios en ellos no se pueden romper compatibilidad estática, sino que podría afectar el tiempo de ejecución.
A través de la revisión de código? – Mrchief
Pregunta relacionada: http://stackoverflow.com/questions/2377855/tool-for-backwards-compatibility-for-the-c-net-api – aponomarenko