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