现在，这个遗留代码是多个项目，每个项目都有自己的解决方案。每个项目通过它编译的dll引用另一个项目。要使主项目运行，您必须以正确的顺序经历10个以上的单独构建。
我试图解释如何在一个解决方案下移动所有项目是解决所有这些问题的好主意。我怎样才能向其他开发者解释这是一个更好的主意？我看不出这是不是一个更好的方式，但是它还是我错了？
现在，这个遗留代码是多个项目，每个项目都有自己的解决方案。每个项目通过它编译的dll引用另一个项目。要使主项目运行，您必须以正确的顺序经历10个以上的单独构建。
我试图解释如何在一个解决方案下移动所有项目是解决所有这些问题的好主意。我怎样才能向其他开发者解释这是一个更好的主意？我看不出这是不是一个更好的方式，但是它还是我错了？
你是对的，我会向其他开发者解释它的好处
对我来说最简单的论据是构建1个时间比构建1个解决方案快10倍。单独加载每个不同的解决方案既繁琐又耗时。 Visual Studio旨在让您的生活更美好，加载解决方案10次不同只会让您的生活变得更糟。
此外，将所有项目放在一个解决方案中意味着您可以获得许多功能的实时支持，如IntelliSense，重构，查找所有引用等等。实时项目引用生成一个 许多 比通过DLL更好的经验。重构是一个特性，它在通过DLL时的实用性受到严重限制。
如果他们担心在迭代根项目时不断重建世界的成本，那么最好的方法是创建一个只构建根项目的新构建配置。解决方案支持多种构建配置，并且它们之间的切换非常快（比在解决方案之间切换快得多）。
我主要同意@JaredPar，但在创建大规模解决方案时需要考虑一些事项。
性能 - 是建设可能不是一项繁琐的任务，但重建一堆不经常改变的“核心”项目会浪费周期，正如Jared所说，你可以通过构建配置来缓解这种情况。此外，Visual Studio往往是一种资源匮乏，根据我的经验，随着解决方案的发展，这个问题会变得更加严重。如果您的核心部件不经常更改，那么一直加载它们的好处是什么？
重构 - 这是一把双刃剑IMO。是的，当加载所有代码时，更容易重命名，移动，替换等。但是，由于它更容易，您也可以遇到这样的情况：从架构的角度来看，人们将添加对项目的引用并跨项目边界移动，这不是正确的方法。因为VS使得它变得如此容易，所以你必须注意盲目重构和破坏架构指南的人
P＆P已就此主题发布了一些指导： http://msdn.microsoft.com/en-us/library/bb668953.aspx
这是一个有点过时的具体谈论TFS，但一些主要概念仍然值得考虑。
你是对的，我会向其他开发者解释它的好处
对我来说最简单的论据是构建1个时间比构建1个解决方案快10倍。单独加载每个不同的解决方案既繁琐又耗时。 Visual Studio旨在让您的生活更美好，加载解决方案10次不同只会让您的生活变得更糟。
此外，将所有项目放在一个解决方案中意味着您可以获得许多功能的实时支持，如IntelliSense，重构，查找所有引用等等。实时项目引用生成一个 许多 比通过DLL更好的经验。重构是一个特性，它在通过DLL时的实用性受到严重限制。
如果他们担心在迭代根项目时不断重建世界的成本，那么最好的方法是创建一个只构建根项目的新构建配置。解决方案支持多种构建配置，并且它们之间的切换非常快（比在解决方案之间切换快得多）。
我主要同意@JaredPar，但在创建大规模解决方案时需要考虑一些事项。
性能 - 是建设可能不是一项繁琐的任务，但重建一堆不经常改变的“核心”项目会浪费周期，正如Jared所说，你可以通过构建配置来缓解这种情况。此外，Visual Studio往往是一种资源匮乏，根据我的经验，随着解决方案的发展，这个问题会变得更加严重。如果您的核心部件不经常更改，那么一直加载它们的好处是什么？
重构 - 这是一把双刃剑IMO。是的，当加载所有代码时，更容易重命名，移动，替换等。但是，由于它更容易，您也可以遇到这样的情况：从架构的角度来看，人们将添加对项目的引用并跨项目边界移动，这不是正确的方法。因为VS使得它变得如此容易，所以你必须注意盲目重构和破坏架构指南的人
P＆P已就此主题发布了一些指导： http://msdn.microsoft.com/en-us/library/bb668953.aspx
这是一个有点过时的具体谈论TFS，但一些主要概念仍然值得考虑。
在本地副本上自己做，然后你可以告诉他们为什么它更好。