我們正在爲我們公司內部的自用測試自動化構建一個.NET軟件平臺。不斷髮展的.NET項目的管理和結構
該應用程序由一個GUI（WinForms）組件和動態加載到其中以執行的各種「動作」組成。
已經有大約100個行動項目已經開始，這個數字在增加。 其中一些項目相互依存於其他項目等。
加載的所有操作都必須引用我們的「SDK」dll以進行各種活動（結果以主應用程序，日誌記錄等）。
有了這個相對簡單的設計，我們正面臨着一些我們希望以最好的方式來解決管理決策：
什麼是這樣的最佳解決方案？爲什麼？
在管理多個鏈接在其間的項目的情況下，常見的做法是什麼？有沒有關於這樣做的提示？
這是沒有一個明確的答案的一個問題，但是......
有您可以採取兩種路徑。強耦合系統或鬆散耦合系統。
對於強耦合系統，我可以爲二進制文件建議兩個目錄：第三方目錄和一個目錄，其中包含您公司構建的DLL，供其他開發人員參考。第三方DLL（公司外部）應位於源代碼管理中，以便所有開發人員從同一位置引用相同版本的第三方DLL，這樣可以避免開發人員機器不一致，並避免在每臺計算機上安裝第三方軟件。內部DLL不應該在源代碼控制中被引用，並且應該通過自動構建批處理文件或類似方式構建在每個開發人員機器上。在構建後步驟中，您可以將它們全部複製到同一目錄，只要開發人員獲得最新的源代碼管理和構建，每個人都擁有公司內部相同的DLL。
例如，獲取最新版本（使用批處理文件構建所需的所有項目），然後作爲後期構建步驟將輸出複製到常用項目。現在，所有其他項目都可以引用來自同一位置的通用compnay DLL和第三方DLL，並且每個人都是一致的。
問題是，這些引用是強耦合的，所以如果傳輸不正確，更改有時可能會出現問題。
一個鬆散耦合的系統使用一個框架，如MEF（管理擴展框架）和組件引用「Contract DLL」，它定義了組件的接口。該項目引用接口或合約DLL，並不真正關心實現，然後MEF爲您管理插件。
在這種情況下，您引用了接口DLL，但不是實現的實際DLL。
例如，假設我有一個名爲LogMessage的方法，它叫做ILog。
private ILog _logger;
_logger.LogMessage();
因此，在強烈耦合的情況下：Action.DLL直接引用Logger.DLL。
在一個鬆散耦合的情況下，Action.DLL引用了ILog.DLL（就是接口）。 Logger.DLL實現ILog.DLL。但是Action.DLL沒有直接引用Logger.DLL。
現在我可以擁有任意數量的提示ILog接口的DLL，但Action.DLL不會直接引用它們。這非常酷，並且是MEF和一般鬆散耦合中更令人興奮的功能之一，也就是不依賴的能力。
你如何選擇去哪裏，無論哪種方式都是可以接受的，我認爲鬆散耦合的想法最適合你的場景，因爲團隊只需要知道合同與實際實施情況。
我不會有一個大規模的合約DLL，我會嘗試將接口分成邏輯分組。例如，日誌記錄看起來像一個實用程序類型的interfance，所以我將創建一個具有ILog接口的實用程序合同DLL。它是如何分裂取決於你想要做什麼。或者每個接口都可以是一個合約DLL，但也許有點極端。
MEF是否可以使用.NET 3.5？ –
這是一個有點複雜的話題，尤其是在.NET領域。我不知道「最佳」解決方案，但我會解釋我們如何管理它;也許你會對自己有用。
這使您可以構建包含大量鏈接項目的大型系統，但會帶來很多複雜性問題。我認爲，這種解決方案可以。
第一：物理結構（我們使用SVN）。
您的版本化\ build文件夾包含構建腳本，例如從常青藤獲取二進制文件，將項目發佈到常青藤或編譯每個項目。當您想要在每個項目中指定持續集成服務器時，它們也會派上用場。
二：要定義依賴來自
答：他們來自您的常春藤庫（它可能是一個網絡共享文件系統一樣簡單）。 您已經創建了您的存儲庫，因此您可以控制其內容。 對於安裝在GAC中的第三方二進制文件要非常小心。視覺工作室是一個痛苦的^^來處理這個問題。
具體做法是：
如何正確驗證所有需要 依賴關係（對 例如第三方庫）確實從 正確位置拍攝？
常春藤給你一個很大的靈活性與依賴關係，它也解決了傳遞依賴;例如，您可以依賴於SDK rev =「1. +」status =「latest.release」，這意味着「SDK的最新穩定版本1.x或SDK rev =」2. +「status =」latest。整合「，這意味着最新的2.x SDK的二進制文件（可能是由持續集成構建產生的）
所以你總是依賴編譯的二進制文件，永遠不要在項目輸出中。第二方依賴關係可能會作爲傳遞到您的SDK上
這也意味着您的項目中的代碼量將保持儘可能小，因爲您需要有可行的Visual Studio解決方案。意味着像ReSharper這樣的重構工具將不再有用，而且還會有一定的複雜度erron你的構建腳本和分支策略。這很大程度上取決於組件的邏輯。
這是一個簡短的概述，如果你認爲這是你想要的東西，我可以擴大答案。祝你好運; .NET生態系統，特別是Visual Studio，並不是真的被認爲是這樣工作的。
我會爲您的SDK提供穩定的接口。當您需要更改界面時，請開發一個新界面並棄用舊界面，但要實施一段時間。我會根據最新的SDK構建每個插件項目。我會考慮MEF或更好的爲我的DI工具，如Autofac。 – kenny
我可能更喜歡「使用給定穩定版本」的方法 - 並且使用NuGet，您可以輕鬆地將SDK和其他支持文件打包到NuGet軟件包中，這些軟件包可以輕鬆安裝到Visual Studio中，並且整潔地更新！ –
我可以在公司內部實施NuGet包嗎？這意味着，允許其他用戶抓取最新的更新而不公開公開我們的代碼？ –