我最近开始为具有旧的旧版代码库的新客户工作，在旧版代码库中有多个.net解决方案，每个解决方案通常托管一些对该解决方案唯一的项目，然后“借用” /“链接”（添加现有项目）其他一些项目从技术上讲，它属于其他解决方案（至少如果您按TFS中的文件夹结构进行操作）
我从未见过如此交错的设置，没有明确的构建顺序，有时解决方案A中的项目只是直接从解决方案B中托管的项目的输出目录中引用dll，有时即使已驻留该项目，也直接将其包括在内FAR在文件夹结构中消失。
似乎所有内容都已针对开发人员的延迟进行了优化。
当我面对他们为什么没有CI服务器时，他们回答说，很难像这样组织代码。（我现在正在设置它并咒骂此代码组织）
这些解决方案是围绕部署工件（需要一起部署的东西在同一个解决方案中）组织的，我认为这是一个明智的决定，但是这些解决方案（项目）的内容无处不在。
在多个解决方案/部署工件之间重用公共类库时，是否存在最佳实践的共识，
Answers:
我从来不喜欢包含属于其他解决方案的现有项目。对一个解决方案对该项目进行编辑会完全破坏另一个解决方案中某些内容的变量太多。然后，通过解决该问题，您最终会破坏原始解决方案。泡沫，冲洗，重复。
当这种依赖关系泄漏到多个解决方案中时，我喜欢将依赖关系代码分离到其OWN解决方案中，并创建一个黑匣子库，然后将其作为参考。我的想法是您的解决方案是相互交织的，因此可以针对每个解决方案在共享项目中进行调试。如果该库是正确构建和测试的，则实际上不需要这种调试。图书馆应该能够站在自己的优点上，并且应该经过全面的测试，以便始终如一地满足任何消费者项目的期望。
我实际上已经像您提到的那样组织了这样的TFS结构，尽管它确实给CI带来了独特的挑战，但是它具有许多不同的好处。一个明显的例子是，它支持并鼓励将适当的组件结构化到单独的.NET项目中，从而通过鼓励100％的测试覆盖率来支持良好的TDD。马上，我注意到您可以解决的一些问题。
有时，解决方案A中的项目只是直接从解决方案B中托管的项目的输出目录中引用dll，有时，即使项目直接位于文件夹结构中，也只是直接包含了该项目。
二进制引用其他目录的输出不是一个好方法，并且在与项目引用混合时也成为一种不好的方法。尝试做一个或另一个，最好至少将二进制引用更改为项目引用以保持一致性。此时，每个解决方案都可以代表一个可构建的应用程序或应用程序层（例如，SuperApp.sln，OtherAppServices.sln，OtherAppPresentationTier.sln）。
要构建所有项目，我建议也创建一个主解决方案。主解决方案将包含所有内容的项目引用，并且本质上是存在的，其唯一好处是拥有一个可处理应用程序套件中所有项目的构建命令。开发人员不应将主解决方案用于主动开发或调试。这使组装构件更加容易。
然后可以使用简单的批处理，powershell或Perl脚本来完成部署。这实际上将构建适当的解决方案或主解决方案，然后将所有内容部署到适当的环境。如果操作正确，可以轻松将其集成到任何CI服务器中。
•如何促进在单独的部署工件之间共享业务逻辑
创建用于通用业务逻辑的项目，或者将关注点更好地分离，以实现更多的全局或通用业务逻辑。希望参考此内容的所有可部署解决方案都应通过项目参考来这样做。
在TFS中组织代码时，通过将公共或共享项目保留在目录树中的更高级别，可以更轻松地实现这一目标。