Có, tôi sẽ (và làm) sử dụng NDepend cho việc này. Tôi làm việc trên một sản phẩm cung cấp API mở rộng cho nhà phát triển. Vì vậy, chúng tôi cần đảm bảo rằng giữa các bản phát hành, chúng tôi không xóa chức năng mà những nhà phát triển đó có thể phụ thuộc. Mặt khác, là chúng ta cần sự linh hoạt để phát triển sản phẩm mà không có những hạn chế lớn xung quanh việc đảo chiều.
Một số điều bạn sẽ muốn cân nhắc.
- Thay đổi phiên bản của DLL được tham chiếu nên được coi là thay đổi đột phá.
- xóa/thay đổi thành viên vi phạm khả năng tương thích ngược.
- thêm thành viên vi phạm khả năng tương thích về phía trước (một số người chỉ xem xét 'các thành viên được thêm vào' an toàn, nhưng nó có rủi ro liên quan).
- Thay đổi phiên bản tệp với mọi bản dựng, bạn sẽ cần nó ở một số thời điểm.
- Cân nhắc viết các hợp đồng xác định 'API công khai' của bạn. Đây sẽ là những thành viên mà bạn cần hỗ trợ bên ngoài tổ chức. Hãy coi chúng là ranh giới khả năng tương tác. Sau đó, nó cho phép các lớp triển khai của bạn có các thành viên công khai, vốn không có trong API (do đó được coi là 'không được hỗ trợ'), vì vậy bạn có thể thay đổi chúng mà không phải lo lắng về việc phá vỡ API mở rộng. Mở rộng API bao gồm viết một giao diện mới (với số phiên bản trong tên giao diện) mà KHÔNG phát sinh từ phiên bản giao diện trước đó (dẫn xuất ngăn bạn khỏi các thành viên không dùng nữa và tạo ra địa ngục khi đến lúc triển khai nhiều phiên bản giao diện trong một lớp học duy nhất.
- Dont quên Thuộc tính, thay đổi để họ có thể không phá vỡ khả năng tương thích tĩnh, nhưng có thể ảnh hưởng đến thời gian chạy.
Qua rà soát mã? – Mrchief
Câu hỏi được liên kết: http://stackoverflow.com/questions/2377855/tool-for-backwards-compatibility-for-the-c-net-api – aponomarenko