为什么我不应该有一个单片实用程序库？
我们有一些常见的库（C＃，但我想这不是平台或语言特定的），让我们称它们为A，B和C.库A引用了B和C，库B引用了第三方DLL，库C独立。 三个独立项目背后的想法是每个库都有不同的function，但随着时间的推移，库A变成了一个或多或少“全能”的公共库，大多数客户端应用程序都引用它。 只有少数应用程序在没有A的情况下引用B和/或C.
我们正在尝试改进我们的源代码控制约定，我们要做的一件事是正确地标记和释放这些库DLL，因此客户端项目文件可以指向代码的静态版本而不是始终更改的主干。 这有点令人费解 – 例如，一个引用A和B的客户端项目.A本身引用B，因此技术上有两个来自客户端项目的B引用。
因此，显而易见的事情似乎是将所有内容组合到一个具有组织良好的命名空间的公共/实用程序库中。 正如我所说，几乎每个客户端应用程序都引用了这些库中的一个，所以谁在乎呢？ 这样做不会引入第三方依赖的任何不良情况，并且我们所有的目标机器都是内部的并且维护大致相同的环境/软件配置。
这似乎太容易解决了，所以我想我至少得到第二个意见。 另一种方法是使用GAC并强烈签署/版本化所有内容。 我在这里错过任何捕获物吗？
我认为你正好合并到一个图书馆。
通常，代码被组件化为太多可部署单元，而逻辑function似乎是分离的标准。 这是错误的IMO。 程序集应与部署方案和发布周期保持一致。 否则，您最终会得到一个非常复杂的依赖图，无论如何，每个程序集都会被管理，构建和部署在一起。
虽然有趣的问题！ 让我们看看其他人的想法:)
这是一个经典的“金发姑娘和3熊”问题。
您不需要单个整体库 – 并且您不需要太多库。 你想要正确数量的库:)不是太多，不是太少，恰到好处。
有不同的库有原因：
1）发展的独立性 – 图书馆可以独立发展。 2）更小的可部署性
我认为一般的经验法则可能是，如果有一个独立的团队专门在图书馆的特定部分进行全职开发，那么它应该是分开的。 如果多个团队不时地在这里和那里添加一些代码，那么开发和部署的独立性应该没有问题，你可能也有一个共同的库。 在您的情况下听起来就是这种情况，因此请使用单个库。
另一个要问的问题是“我们目前遇到的问题是分拆图书馆解决方案？” 如果它没有解决任何问题，那么就不需要单独的库。
观点1
尽可能少的库简化了构建脚本和部署（需要担心的部分更少）。 拥有一个包含所有内部开发的UI组件的库非常适合启动新项目。 只需添加一个参考，您就可以准备好所有内部组件。 希望这减少了重新发明组件所花费的时间，因为有人忘了已经有一个带有这样组件的库。 通用实用程序库也是如此 – 只有一个实用程序库更好，因此您可以通过一个引用获得所有可用function。
观点2
将各种相关function部分分离到单独的库中可以使这些库集中，并使其意图清晰。 由于每个库都更集中，每个库都会更小。 因此，您的最终部署包可以更小，因为您只包含实际需要的库。 但是，您必须记住您拥有的库以及每个库包含的库。 这可能是文档和知识转移的噩梦。
那么对您来说，更重要的是部署规模还是开发人员的可用性？ 选择优先级，然后将代码组织与其匹配。
我同意为这些实用程序设置单个库是理想的，只要命名空间得到适当维护并且代码本身可以很好地分解，以便将来对库进行任何维护。 我看到的主要理由正如您所提到的，几乎所有内部应用程序都在使用它。
但是，要考虑的一件事是这些部分的function。 如果一个部分是实用程序命名空间，用于使用控件或标签执行巧妙的技巧，第二部分是处理登录过程的安全库，当“酷技巧D”被添加到实用程序库时，您可能会遇到一些意外的问题，但打破了依赖于安全库的现有应用程序，但由于整个DLL现已更新，因此必须进行升级。
您可以考虑以消除交叉依赖关系的方式重写所有三个库，并查看是否为您当前和未来的应用程序提供了更好的整体情况。
可能有理由为具有完全不同目的的库或引用第三方库的项目创建单独的项目。 除此之外，你可以把大多数放在一个共同的基础图书馆。
我们有一个用于很多类的公共库，但是一个用于Web相关类的单独项目，一个用于PDF相关类的单独项目（因为它使用了我们在所有应用程序中不需要的第三方DLL），一个单独的项目MySQL相关类（因为它使用第三方连接器）。
我们还有一个单独的数据库（MS SQL）相关类项目，但这可能真的进入了公共库，因为我们有很少的应用程序不使用数据库。
我会说它真的只归结为最适合你的东西。 一个很大的工具库可能很难找到东西，但是然后又一次又一次，每个人都知道在哪里可以看到它们可能会带来更多好处。 还取决于库的管理方式，不同的组可能更容易维护自己的util库（如果他们需要控制对它们的更改），但如果它由一个组管理（或者如果每个人都相处）那么一个大的一个可能更容易。 所以真的对你有用。
只是分享一些最近的经验，这使我在这方面略有改变……
将解决方案中的150个项目减少到大约30个，将我们的构建时间缩短到原来的25％（1分钟，在我们典型的开发机器上更改为5分钟）。 如果您正在进行dll引用，那并不重要，但如果您将项目包含在主解决方案中，您可能会发现它很重要。 说实话，我对这种差异感到有些惊讶，但过去的结果并不能保证未来的回报。
每次.net第一次加载一个dll，你承担JIT-ing和文件I / O开销。 对于WinForm / WPF应用程序，用户可以每天多次启动它，这比Web应用程序更受关注。 即使对于Winform / WPF应用程序，它也许不是很多应用程序的关注点。
要注意的另一件事是错综复杂的依赖性，这会导致“如果我使用A，我必须使用B，因为A暴露来自B的类型。同时，我很少使用B本身”只需将它组合并完成它。
所以，我的理解是有一些具体的理由试图巩固。 可能有一百万个主观原因，但在一个大型解决方案文件中，似乎更好的尝试变得简单，因为你可以合理地完成。
更主观的是，我还鼓励您将项目文件视为构建工件，而不是代码工件。 将.cs文件视为您真正想要重用的内容而不是.csproj。 当然，大多数时候你也会重复使用.csproj，并且只是一直以相同的方式构建程序集。 但是，不要试图强迫自己拥有依赖项或比项目中实际需要的更多代码。 大多数时候.csproj和.cs之间的关系相当松散。
编辑：@ – 添加“在你的项目中”