在我工作的公司，我们有一个“实用程序”项目，我们构建的几乎所有应用程序都引用了该项目。它有很多东西，比如 NullHelpers、ConfigSettingHelpers、Common ExtensionMethods 等。
我们的工作方式是，当我们想要创建一个新项目时，我们从源代码管理中获取最新版本的项目并将其添加到解决方案中，然后从添加到解决方案中的任何新项目中引用该项目。
这工作正常，但是在某些情况下，人们对公共项目进行了“重大更改”，这对他们有用，但对其他人不起作用。
我一直在想，与其将公共库添加为项目参考，不如开始将公共库开发为独立的 dll 并发布不同的版本，并针对特定项目的特定版本进行更改，这样就可以在没有任何风险的情况下进行更改到使用公共库的其他项目。
说了这么多，我很想看看其他人如何引用或使用他们的公共库。
这正是我们正在做的事情。我们有一个实用项目，它有一些非项目特定的有用功能。我们手动增加版本（次要），在 Release 版本中构建项目，签名并将其放到共享位置。
然后人们使用特定版本的库。
如果在某些特定项目中实现了一些有用的方法，这些方法可以进入主实用程序项目，我们将它们放入项目中的一个特殊帮助器类中，并将它们标记为可能的实用程序候选者（简单 //TODO）。在项目结束时，我们审查候选人，如果他们坚持，我们将他们移动到主库。
重大更改是禁忌，如果需要，我们会将方法和类标记为 [已过时]。
但是，这并不重要，因为我们会在每次发布时增加版本。
希望这可以帮助。
我们在源代码控制中使用分支；每个人都使用 head 分支，直到发布。当他们分支发布时，他们也会分支公共实用程序项目。
此外，我们的实用程序项目有自己的单元测试。这样，其他团队可以知道他们是否会破坏其他团队的构建。
Of course, we still have problems like you mention occasionally. But when one team checks in a change that breaks another team's build, it usually means the contract for that method/object has been broken somewhere. We look at these as opportunities to improve the design of the common utilities project... or at least to write more unit tests :/
我遇到了完全相同的问题！
我曾经使用项目引用，但这一切似乎都很糟糕，正如你所说，你有很多项目引用它。
我现在编译为 DLL，并在第一次构建后将 DLL 引用的 CopyLocal 属性设置为 false（否则我发现它会覆盖子项目而变得一团糟）。
我想理论上它可能应该是 GAC 的，但如果它的问题发生了很大的变化（就像我的那样），这可能会成为问题..