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

Question

在我的团队中，我们有数百个共享的dll文件，其中许多还引用了其他dll文件，这些文件本身又引用其他dll文件，依此类推。我们已经开始使用一个“共享”目录来存放所有我们认为足够通用以在其他项目中使用的dll文件，例如数据库通信dll。

问题是，如果树形结构下的任何一个dll文件被更改，那么引用它的所有内容都需要重新编译以避免版本问题（这会在运行时发生）。

为避免这种情况，现在有人提议将我们所有的“共享”dll文件添加到一个大型程序集中，任何创建新应用程序的人只需引用它，仅需引用该程序集。

显然，这个程序集将变得越来越大，我不确定这是否是最好的方法。请问您有什么想法？

- HAdes

Answer 1

我们所做的是把共享的DLL维护视为一个独立的项目，拥有自己的源代码控制等。然后每年大约两次，我们会发布共享的DLL到公共场合，带有自己的版本号等。只要您始终将DLL作为“集合”使用（意味着您引用的所有DLL都来自同一版本），则保证不会出现任何依赖性问题。

- GWLlosa

Answer 2

这绝对不是最好的方法。我在工作中有一些类似的“共享”DLL。它们变得笨重和难以（读作：不可能）进行有意义的更改，因为确保更改不会破坏下游应用程序变得太困难，这似乎与您试图做的相反。

听起来你真正需要做的是更好地分离你的关注点。如果所有这些DLL都相互引用，它们可能过于紧密耦合。真正的“共享”DLL应该能够独立存在，或者作为三个或四个组成部分之一。如果你的依赖关系实际上阻止你进行更改，那么你的耦合策略就出了大问题。

把所有东西都放在一个大的DLL中肯定不会让任何事情变得更好。事实上，可能相反。一旦你把所有东西都放在一个DLL中，就会有诱惑力把其中的所有东西更加紧密地耦合在一起，这将使以后无法拆分。

- DannySmurf

Answer 3

你可以创建一个包含所有相关项目的解决方案。
当你需要发布时，只需构建此解决方案即可。

---

更新。
正如你所说，解决方案无法容纳太多的dll文件。
另一方面，你可以使用外部MSBuild脚本 或者使用CruiseControl.NET来完成这些复杂的任务。

- Avram

---

那样做是可行的，但意味着需要将所有项目加载到Visual Studio中，而且在添加太多项目后，我认为它不会很响应。此外，即使使用后构建脚本，这也意味着需要手动管理每个项目的已编译dll。 - HAdes

Answer 4

引用GoF书中的话，“面向接口编程，而不是实现。”这个原则也适用于你的一些库。当你的耦合度很高时，你已经意识到了你的开发变得多么脆弱。现在需要解决的问题是如何给你留出呼吸空间。

• 你可以创建一个接口。这将提供一个契约，任何应用程序都可以使用它来指定可用的最小功能集。

• 你可以创建一个实现接口的服务。这将允许你提供被认为是插件或附加组件的内容。这使你可以设计一个遵循契约版本并期望你的工具遵守的协议。

• 你可以创建一个只使用接口的服务。这将允许你的应用程序发送任何符合设计契约的具体实现。

像开发编辑器和Web浏览器这样的产品使用这种方法来实现一些代码重用。谢谢。祝您好运。

《设计模式中的设计原则》

插件

- Yemi Bedu