在我的团队中，我们有数百个共享 dll，其中许多还引用了其他 dll，这些 dll 本身也引用了其他 dll，依此类推。我们已经开始为所有我们认为足够通用以在其他项目中使用的 dll 使用“共享”目录，例如数据库通信 dll。
问题在于，如果整个树中的一个 dll 被更改，那么引用它的所有内容都需要重新编译以避免版本控制问题（在运行时发生）。
为避免这种情况，现在有人谈论将我们所有的“共享”dll 添加到一个大程序集中，任何创建新应用程序的人都只需引用它，并且仅此而已。
这显然会变得越来越大，我不确定这是否是最好的方法。请问有什么想法吗？
【问题讨论】：
标签： c# visual-studio dll
我们所做的是将共享 DLL 的维护本身视为一个项目，具有自己的源代码控制和一切。然后大约每年两次，我们向公众“发布”共享 DLL，带有自己的版本号和所有内容。只要您始终将 DLL 用作“集合”（意味着您引用的所有 DLL 都来自同一版本），就可以保证不会有任何依赖问题。
【讨论】：
这绝对不是最好的方法。在我的工作中，我有一些类似的“共享”DLL。它们变得笨重且难以（阅读：不可能）进行有意义的更改，因为很难确保更改不会破坏下游应用程序，这似乎与您尝试做的完全相反。
听起来你真正需要做的是更好地分离你的关注点。如果所有这些 DLL 都相互引用，那么它们可能耦合得太紧了。一个真正的“共享”DLL 应该能够独立存在，或者作为一个包含三个或四个组的数据包的一部分。如果您的依赖项实际上阻止您进行更改，那么您的耦合策略就大错特错了。
将所有内容放在一个大型 DLL 中肯定不会让任何事情变得更好。事实上，可能恰恰相反。一旦您将所有内容都放在一个 DLL 中，就会很想将其中的所有内容更紧密地耦合在一起，这样以后就不可能再分开了。
【讨论】：
您可以制作一个包含所有关联项目的解决方案。
当您需要发布时，只需构建此解决方案
更新。
正如你所说，解决方案是不能容纳这么多的 dll。
另一方面，您可以制作一个外部 MSBuild 脚本
或使用 CruiseControl.NET 有可能完成如此复杂的任务。
【讨论】：
引用 GoF 书中的内容，“编程为接口，而不是实现。” 这可能适用于您的某些库。你已经意识到当你有紧密耦合时你的开发变得多么脆弱。现在需要解决的是如何给你喘息的空间。
您可以创建一个接口。这将提供一个契约，任何应用程序都可以使用该契约来指定可用的最小功能集。
您可以创建一个实现接口的服务。这将允许您提供被认为是插件或插件的内容。这使您可以根据您的工具将遵守的期望来设计合同版本。
您可以创建仅使用接口的服务。这将允许您的应用程序发送任何符合设计合同的具体实现。
开发编辑器和 Web 浏览器等产品使用这种方法使某些代码重用成为可能。谢谢你。美好的一天。
【讨论】：