我们有一些通用库(C#，但我想这不是特定于平台或语言的)，我们称它们为 A、B 和 C。库 A 引用了 B 和 C，库 B 有对第 3 方 DLL 的引用，库 C 是独立的。三个独立项目背后的想法是每个库都有不同的功能，但随着时间的推移，库 A 已或多或少成为大多数客户端应用程序引用的“包罗万象”的通用库。只有少数应用在没有 A 的情况下也引用 B 和/或 C。
我们正在努力改进我们的源代码控制约定，我们正在努力做的一件事是正确标记和发布这些库 DLL，因此客户端项目文件可以指向代码的静态版本，而不是始终-换行李箱。这证明有点令人费解 - 例如，一个同时引用 A 和 B 的客户项目。A 本身引用 B，因此从技术上讲，有两个来自客户项目的 B 引用。
因此显而易见的事情似乎是将所有内容组合到一个具有组织良好的 namespace 的通用/实用程序库中。正如我所说，几乎每个客户端应用程序都引用这些库之一，所以谁在乎呢？这样做不会引入任何与第 3 方依赖项有关的不良情况，并且我们所有的目标计算机都是内部的，并且保持大致相同的环境/软件配置。
虽然这似乎是一个简单的解决方案，但我认为我至少会征求第二意见。另一种方法是使用 GAC 并对所有内容进行强签名/版本控制。我在这里漏掉了什么吗？
最佳答案
我认为您将合并到一个库中是对的。
代码经常被组件化为太多的可部署单元，而功能的逻辑部分似乎是分离的标准。这是错误的国际海事组织。相反，程序集应该与部署场景和发布周期保持一致。否则，您最终会得到一个极其复杂的依赖关系图，其中无论如何每个程序集都是一起管理、构建和部署的。
不过这个问题很有趣!让我们看看其他人的想法:)
关于c# - 为什么我不应该有一个单一的整体实用程序库？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1943320/