我们有一些通用库（C#，但我想这不是特定于平台或语言的），我们称它们为 A、B 和 C。库 A 引用了 B 和 C，库 B 引用了第三方 DLL，库 C 是独立的。三个独立项目背后的想法是，每个库都有不同的功能，但随着时间的推移，库 A 或多或少成为了大多数客户端应用程序都会引用的“包罗万象”的通用库。只有少数应用程序引用了 B 和/或 C，而没有引用 A。
我们正在努力改进我们的源代码控制约定，我们正在尝试做的一件事就是正确标记和发布这些库 DLL，以便客户端项目文件可以指向代码的静态版本，而不是始终变化的主干。事实证明，这有点复杂 - 例如，一个客户端项目同时引用 A 和 B。A 本身引用 B，因此从技术上讲，有两个来自客户端项目的对 B 的引用。
因此，显而易见的事情似乎是将所有内容合并到一个具有组织良好的命名空间的通用/实用程序库中。正如我所说，几乎每个客户端应用程序都会引用这些库之一，所以谁在乎呢？这样做不会引入任何与第三方依赖项相关的不良情况，并且我们所有的目标机器都是内部的，并保持大致相同的环境/软件配置。
但这似乎是一个太简单的解决方案，所以我想我至少会得到第二个意见。另一种方法是使用 GAC 并对所有内容进行严格签名/版本控制。我在这里遗漏了什么吗？
我认为你整合到一个库中是正确的。
很多时候，代码被组件化为太多的可部署单元，而功能的逻辑部分似乎是分离的标准。国际海事组织这是错误的。程序集应该与部署场景和发布周期保持一致。否则，您最终会得到一个极其复杂的依赖关系图，其中无论如何每个程序集都是一起管理、构建和部署的。
不过很有趣的问题！让我们看看其他人的想法:)
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
