使用TFS檢測.NET代碼中的重大更改？

每當TFS構建解決方案時，我都希望檢測到.NET代碼（特別是C＃）的重大更改。如果在檢入的代碼和最近成功構建的版本之間有任何重大更改（如「A definite guide to API-breaking changes in .NET」中所述），我想知道它。重大更改不一定會導致構建失敗。編寫一個使用反射來比較同一程序集的兩個版本的應用程序，這怎麼能做到呢？使用TFS檢測.NET代碼中的重大更改？

來源

2011-08-30 jalbert

通過代碼審查？ – Mrchief

鏈接的問題：http://stackoverflow.com/questions/2377855/tool-for-backwards-compatibility-for-the-c-net-api – aponomarenko

是的，我會（並且）爲此使用NDepend。我致力於爲開發人員提供可擴展API的產品。因此，我們需要確保在發佈之間，我們不會刪除那些開發人員可能依賴的功能。另一方面，我們需要靈活性來擴大產品的範圍，而不會對版本造成大的限制。

有些事情你會想要考慮。

更改被引用的DLL的版本應被視爲重大更改。
刪除/更改成員可以降低向後兼容性。
添加成員打破了兼容性（有些人認爲「添加成員」是安全的，但它確實有風險相關）。
更改每個版本的文件版本，您將在某個時候需要它。
考慮編寫定義您的'公共API'的合同。這些將是您需要在組織外部提供支持的成員。將它們視爲互操作性邊界。然後它允許您的實現類擁有公共成員，這些公共成員不在API中（因此被認爲是「不受支持」），因此您可以更改它們而不必擔心打破擴展性API。擴展API包括編寫一個新的接口（帶有接口名稱中的版本號），它不會從接口的先前版本派生（派生阻止您完全棄用成員，並且在實現多個接口版本時創建地獄在一個類中。
不要忘記屬性，改變他們可能不會打破靜態的兼容性，但可能會影響運行。

來源

2011-09-12 05:19:28 Adam

詳細說明＃1？如果我的Apple.dll依賴於Bear.dll的v1版，並且我升級到了Bear.dll的v1.2版本，並驗證Bear.dll不會按照其他＃2-6公開任何重大更改？ Apple.dll用戶不應該因爲正確的結果而遭受任何破壞？只要我確保所有引用的dll都符合相同的標準，無論何時我更新引用的DLL，那麼應該沒有問題是正確的？ – AaronLS

嗨AaronLS。這是一個很好的問題，我原本應該詳細闡述＃1。如果Apple.dll的公共功能返回在Bear.dll中聲明的類型，則會出現風險。如果這些程序集是強類型的，那麼依賴於Apple的產品將期望該函數調用返回（完全限定類型名稱）「Type，Bear，v1.1」。如果你的Apple.dll有「hot fixed」（已更改但未被反編譯），它現在將返回「Type，Bear，v1.2」，並且運行時會拋出類拋出異常 - 因爲強命名類型被所有名稱組件，包括版本。 – Adam