在C＃中處理共享dll的最佳方法是什么？

Question

在我的團隊中，我們有數百個共享的dll，其中許多還引用了其他dll，而這些dll本身也引用了其他dll，依此類推。 我們已經開始對所有我們認為足以在其他項目（例如數據庫通信dll）中使用的dll使用“共享”目錄。

問題在於，如果更改了整個樹中的所有dll之一，則需要重新編譯所有引用它的dll，以避免版本問題（在運行時發生）。

為避免這種情況，現在有人談論將我們所有“共享”的dll添加到一個大程序集中，並且任何創建新應用的人都只是引用該引用，並且僅此引用。

這顯然會越來越大，我不確定這是否是最好的方法。 有什么想法嗎？

Answer 1

我們要做的是將共享DLL的維護本身視為一個項目，並帶有其自己的源代碼管理和所有內容。 然后大約每年兩次，我們使用自己的版本號和所有內容向公眾“發布”共享的DLL。 只要您始終將DLL用作“集合”（意味着您引用的所有DLL都來自同一發行版），就可以保證不會有任何依賴性問題。

Answer 2

絕對不是最好的方法。 我的工作中有一些類似的“共享” DLL。 由於難以確保更改不會破壞下游的應用程序，它們變得笨拙且難以（難以理解）進行有意義的更改，這似乎與您嘗試做的事情完全相反。

聽起來您真正需要做的是將您的關注點更好地分離。 如果所有這些DLL相互引用，則它們可能耦合得太緊密。 真正的“共享” DLL應該能夠獨立存在，也可以作為一個整體傳播的三到四個數據包的一部分。 如果您的依賴關系實際上阻止了您進行更改，那么耦合策略就大錯特錯了。

將所有內容放到一個大的DLL中肯定不會使任何事情變得更好。 實際上，可能恰恰相反。 一旦將所有內容都放在一個DLL中，就會有誘惑將其中的所有內容更緊密地耦合在一起，這將使以后無法將它們拆開。

Answer 3

您可以制定一個包含所有關聯項目的解決方案 。
當您需要發布時，只需構建此解決方案

---

更新。
正如您所說，解決方案無法容納那么多dll。
另一方面，您可以制作一個外部MSBuild腳本 或使用CruiseControl.NET來執行這樣的復雜任務。

Answer 4

引用GoF的書中的“編程接口，而不是實現”。 這可能適用於您的某些庫。 您已經意識到當緊密耦合時，開發會變得多么脆弱。 現在需要解決的是如何為您提供呼吸空間。

• 您可以創建一個界面。 這將提供任何應用程序都可以用來指定可用的最小功能集的合同。

• 您可以創建實現接口的服務。 這將允許您提供被認為是插件或插件的東西。 這使您可以朝着合同版本進行設計，並期望您的工具能夠遵守。

• 您可以創建僅使用接口的服務。 這將允許您的應用程序發送遵守設計合同的任何具體實現。

開發編輯器和Web瀏覽器之類的產品使用這種方法來使某些代碼重用成為可能。 謝謝。 美好的一天。

設計模式中的設計原理

插入