Sì, vorrei (e faccio) usare NDepend per questo. Lavoro su un prodotto che fornisce un'API estendibile per gli sviluppatori. In quanto tale, dobbiamo fare in modo che tra una release e l'altra non rimuoviamo la funzionalità da cui questi sviluppatori possono dipendere. Il rovescio della medaglia, è che abbiamo bisogno della flessibilità per far crescere il prodotto senza enormi vincoli attorno al ritorno.
Alcune cose che si vuole prendere in considerazione.
- La modifica della versione di una DLL di riferimento deve essere considerata una modifica inattesa.
- rimozione/modifica membri interrompe la compatibilità all'indietro.
- membri aggiungendo rompe la compatibilità in avanti (alcune persone considerano come sicuro 'membri aggiunti', ma ha un rischio associato).
- versione del file cambiare ad ogni generazione, sarà necessario che a un certo punto.
- Considera di scrivere contratti che definiscono la tua "API pubblica". Questi saranno i membri che è necessario supportare al di fuori dell'organizzazione. Pensa a loro come a confini di interoperabilità. Quindi consente alle classi di implementazione di avere membri pubblici, che non sono nell'API (quindi considerati "non supportati"), quindi è possibile cambiarli senza preoccuparsi di rompere l'API di estensibilità. Estendere l'API consiste di scrivere una nuova interfaccia (con un numero di versione nel nome dell'interfaccia), che non deriva dalla versione precedente di interfaccia (derivazione vi impedisce di membri a pieno di disapprovazione, e crea l'inferno quando arriva il momento di realizzare versioni di interfaccia multipli in una singola classe.
- non dimenticare gli attributi, le modifiche al loro non possono rompere la compatibilità statica, ma potrebbe influenzare il tempo di esecuzione.
Attraverso la revisione del codice? – Mrchief
Domanda collegata: http://stackoverflow.com/questions/2377855/tool-for-back-compatibility-for-the-c-net-api – aponomarenko