在我的團隊中，我們有數百個共享dll，其中許多還引用其他dll自己引用其他dll，等等。我們已經開始爲所有我們覺得足夠通用的dll使用'Shared'目錄，以便在其他項目中使用，例如數據庫通信dll。在C＃中處理共享dll的最佳方式是什麼？
的問題是，如果這些DLL一路下滑樹的一個改變，那麼一切都引用它需要重新編譯，以避免版本問題（發生在運行時）。
爲了避免這種情況，現在談加入我們所有的「共享」的DLL到一個大集會，和任何人創建新的應用程序簡單地引用，這本身。
這顯然會變得越來越大，我不知道這是最好的方法還是不行。請任何想法？
這絕對不是最好的辦法。我在我的工作中有幾個「共享」的DLL，就是這樣的。他們變得笨拙和困難（閱讀：不可能）做出有意義的更改，因爲變得難以確保更改不會破壞下游應用程序，這看起來與您正在嘗試執行的操作完全相反。
這聽起來像你真正需要做的是分開你的關注點好一點。如果所有這些DLL都相互引用，它們可能會緊密耦合。一個真正的「共享」DLL應該能夠獨立存在，或者作爲三個或四個分組旅行的一部分。如果你的依賴關係實際上阻止你做出改變，那麼你的耦合策略已經發生了可怕的錯誤。
把一切放在一個大的DLL當然不會讓事情變得更好。事實上，可能是相反的。一旦你在一個DLL中獲得了所有的東西，誘惑將會在那裏把它裏面的所有東西緊緊地聯繫在一起，這將使得事情不可能在以後分離出來。
我們做的是治療共享DLL的維護，本身就是一個項目，擁有自己的源代碼控制和一切。然後，每年大約兩次，我們向公衆發佈共享DLL的「釋放」，並帶有其自己的版本號和所有內容。只要你總是使用DLL作爲'set'（意味着你引用的所有文件都來自同一個版本），你就可以保證不會有任何依賴性問題。
可以使一個解決方案，包括所有連接的項目。
當你需要釋放，只是構建此解決方案
更新。
正如你所說，解決方案不能容納這麼多dll。
在另一方面，你可以使用CruiseControl.NET有可能做出這樣複雜的任務使外部MSBuild腳本 或。
從GoF的書，引述「計劃，以一個接口，而不是實現。」這可能適用於您的一些圖書館。你已經意識到當你緊密耦合時你的發展變得脆弱。現在需要解決的是如何給你喘息的機會。
您可以創建一個接口。這將提供一個合同，任何應用程序都可以使用該合同來指定可用的最小功能集。
您可以創建一個實現接口的服務。這將允許你提供什麼被認爲是插件或插件。這使您可以設計一個契約版本，並期望您的工具能夠遵守。
您可以創建僅使用接口的服務。這將允許您的應用程序發送符合設計合同的任何具體實現。
像開發編輯器和Web瀏覽器這樣的產品使用這種方法來使一些代碼重用成爲可能。謝謝。美好的一天。
這將工作，但將意味着所有的項目加載到Visual Studio中，我不覺得被添加太多的項目後，這將是非常敏感的。此外，它意味着必須手動管理每個項目的編譯dll，即使使用後構建腳本例如。 – HAdes 2009-02-11 21:48:45