Visual Studio：单一解决方案还是很多解决方案？

Question

现在这个遗留代码是多个项目，每个项目都有自己的解决方案。每个项目都通过编译后的dll引用另一个项目。要让主项目运行，你必须按照正确的顺序通过10个以上的个人构建。

我想解释如何在单一解决方案下移动所有项目是解决所有这些问题的好主意。我怎样才能向其他开发者解释这是一个更好的主意？我不明白这不是一条更好的路，但是我还是错了？

Answer 1

你是正确的，我会解释给其他开发商的利益

对我来说，最简单的说法是建筑方面1周时间大于1个号楼解决方案的10倍快的多。单独加载每个不同的解决方案是非常繁琐和耗时的。 Visual Studio是关于让你的生活更美好，加载10次不同的解决方案只会让你的生活变得更糟。

而且把所有的项目在一个解决方案意味着你得到了很多功能，如智能感知，重构现场支持，查找所有引用等..有现场项目引用产生比通过的DLL去一个多更好的体验。重构是一个在通过DLL时非常有用的特性。

如果他们担心在根项目上迭代时不断重建世界的成本，那么最好的方法是创建一个只构建根项目的新构建配置。解决方案支持多种构建配置，它们之间的切换速度非常快（比解决方案之间的切换快得多）。

Answer 2

自己动手做一个本地副本，然后你可以告诉他们为什么它更好。

Answer 3

我主要同意@JaredPar，但是在创建一个大规模解决方案时需要考虑几件事情。

1. 性能 - 是的建筑可能是少了繁琐的任务，但重建为数众多的改变很少浪费周期，正如贾里德说你可以构建CONFIGS缓解这种“核心”项目。另外，Visual Studio往往成为一个资源浪费问题，根据我的经验，随着解决方案的增长，问题会加剧。如果你的核心部件不经常改变，那么一直加载它们的好处是什么？

2. 重构 - 这是一把双刃剑IMO。是的，当所有的代码都被加载时，重命名，移动，替换等操作更容易。然而，由于它更容易，所以当从架构的角度来看，这是不正确的方法时，人们会添加对项目的引用并跨项目边界移动事物。因为VS使得它很容易做到，你必须提防的人盲目重构，打破建筑的准则

P & P具有发表关于这一主题的一些指导：http://msdn.microsoft.com/en-us/library/bb668953.aspx

这是一个有点过时和专门讨论TFS，但一些主要概念仍然值得考虑。