我們有很多不同的解決方案/項目由不同的團隊管理。我們的解決方案需要引用另一個團隊擁有的多個項目。我們不想將這些依賴添加爲項目引用，因爲我們不打算修改該代碼，我們只是想使用它。此外，我們的解決方案中已經有相當多的項目，並且不想再增加更多，因爲它會減慢Visual Studio的速度。所以我們在一個單獨的解決方案中構建這些項目並將它們作爲文件引用添加到我們的解決方案中管理內部第三方依賴關係
我的問題是，人們如何管理這些類型的依賴關係？我是否應該有一個自動化流程，尋找這些項目的變化，構建它們並將這些dll檢入到我們的源代碼控制中，之後我們會像其他第三方依賴項那樣對待它們？有推薦的方法嗎？
一個解決方案，儘管它可能不一定是你正在尋找的是，讓每個從屬子系統執行一個版本。這個版本可以是MSI安裝形式，也可以是組件的網絡共享。當發生重大變化時，該團隊可以讓您知道，並且您可以運行安裝或腳本來複制文件。
一旦你發佈了，你可以把它們放到GAC中，這樣你就不用擔心把它們複製到你的項目bin文件夾中。
假設您正在使用構建服務器或某種類型的持續集成，另一種解決方案是在構建後階段或過程階段對文件進行構建。在任何特定時刻，其他團隊的開發人員都可以獲取新文件，或者讓腳本或bat文件在本地將其拉下。
編輯 - 其他解決方案 最好問你爲什麼有這些依賴關係？構建應用程序的一部分時，你真的需要它們嗎？您可以嘲笑解決方案中的依賴關係，允許您編寫，構建和運行單元測試嗎？實際的應用程序會將它們連接到DEV/Test/Prod環境中。保持解決方案解耦和免費可能是個人團隊的更好解決方案。當應用程序以真實設置運行時，保留集成和耦合。
第一個解決方案就是我們目前使用的。我不喜歡這個，因爲團隊成員並不總是讓你知道，你最終會使用過時的dll版本。 CI解決方案是我們目前正在考慮的內容，但我們正在考慮讓CI構建這些依賴關係，並將它們提交到版本控制中，以便如果開發人員獲得最新版本，他將自動獲取它們。 – 2010-07-09 01:19:30
我已經看到團隊之前以這種方式提交二進制文件到源代碼控制。它確實有效。通常情況下，將二進制文件提交到SOURCE控件不是最佳實踐。 – 2010-07-09 16:32:52
不是「內部」和「第三方」的正交術語嗎？ :-) – Gray 2014-02-24 21:05:57