Visual Studio项目应该包含在多个解决方案中吗？
注意：这是适用于C++，C++/CLI和C＃的商店，其中一些产品以三种产品的组合形式交付。Visual Studio项目应该包含在多个解决方案中吗？
我们目前有一个规则，即项目应该只有一个包含解决方案。该规则最初是由于Visual Studio的源代码管理插件无法处理多个解决方案中包含的项目而导致的，因此当从一个解决方案更改为另一个解决方案时，总是尝试更改源控制绑定。
由于其他原因，我们将完全停止使用源代码管理插件（而不是放弃源代码管理，只是大脑死亡插件）。它重新提出了是否继续限制项目的政策只能包含在一个解决方案中的问题。
我们在多个可交付产品所使用的库，dll和程序集中有相当多的代码，而且我们目前使用一个解决方案间依赖性管理系统来控制此问题，因此如果有人正在解决方案中工作最终产品，请求构建依赖性解决方案是一件简单的事情，该解决方案会启动Visual Studio的其他实例来构建它们。该系统的工作原理，但有以下缺点：
- 为共同的项目解决方案通常太胖，包含由产品所需的几个项目目前正在开发和平时多了很多不需要的了开发工作在手边。他们仅仅被纳入一种涵盖所有松散相关项目的全面解决方案。由于编译了不需要的代码，这会导致编译时间延长。
- 在我们试图解决上述胖解决方案的过程中，我们经常会留下一个太瘦的解决方案，其中只包含一个项目。其中每一项都需要在解决方案间依赖性管理系统中进行额外配置。这也可以在Visual Studio的多个实例被启动时增加构建时间。
我在考虑修改政策，允许多个可交付产品中使用的项目包含在多个解决方案中。我们可以消除解决方案间依赖关系管理，并大大减少解决方案的数量（每个产品最多可减少一个）。我担心这次重组的工作量以及是否值得付出努力。恐怕在团队一直工作之前，我甚至无法发现潜在的益处。我还预见了一些潜在的问题，这是真正的问题。
- 在单一解决方案中执行大量项目会在Visual Studio 2005（我们当前的开发平台）中出现任何稳定性问题吗？它在VS 2008或VS 2010中有更好的表现吗？
- 如果项目包含在多个解决方案中，如果项目配置被修改（如添加新配置），如何管理对多个解决方案的影响？
对于任何的环境已经工作与每个可交付的产品一个解决方案，具有共同的构成零件包含在多个项目的解决方案：你有没有遇到任何显著缺点，这样的配置？
不，请使用尽可能多的解决方案。
例如，我们有一个大型解决方案，可以构建大约53个项目。它包含一个安装程序和卸载程序，以便它们可以方便地由我们的构建服务器构建，但如果我想要处理这些应用程序，我将它们加载到它们自己的解决方案中（每个项目有一个项目），而不是一直装载其他69个项目不必要的项目他们对其他项目没有任何依赖性，所以这样做没有任何问题（实际上，解决方案的加载和构建方式更快，效率更高）
多种解决方案唯一的解决方案是在任何情况下，如果你没有建立依赖关系，你必须小心谨慎（例如，如果你不建立一个库，那么你需要小心，当它的源代码发生变化时它就会被建立，因为它不会再为你自动建立）
编辑
要回答你的问题的最后一部分（因为有需要的问题路程，而找你e编辑答案！），VS2005中解决方案唯一的问题是它的速度很慢，其中包含很多项目。 VS2008是很多在加载大型解决方案时速度更快，但主要目的只是解决方案中的项目越多，构建所需的时间越长（即使它只是跳过不需要构建的项目，需要很长时间）
如果您添加一个新的解决方案配置，那么只需制作一个超级解决方案（或保留现有的解决方案！），然后对其进行修改，以便将其应用于所有项目一气呵成。您仍然必须将该新配置添加到您要使用的任何单独解决方案中，但是如果它们是单项目解决方案，则可以将其删除，然后加载.csproj，并且会自动重建所有配置中的配置它。并且增加新的配置可能不会经常发生。
我也在一个环境中工作，这个环境有很多常用项目在几个可交付成果中使用。我们的政策是每个可交付应用的一个解决方案。所以一个共同的项目可能包含在几个解决方案中。这对我们非常有效。常见的项目虽然包含在单独的解决方案中，但都映射到相同的源代码存储库位置。因此，如果通用代码发生更改，所有包含的应用程序都会受到影响（我们的持续集成系统）可用作检查其他应用程序是否因通用代码更改而中断。
您在VS解决方案中拥有的项目越多，加载所需的时间就越长，并且听起来很复杂，因此无法在单个解决方案中管理不同的构建配置和依赖项。
用具有几种解决方案，一个项目的主要问题是：
- 如果您在项目中的变化，它可以在使用它的另一种解决方案会导致编译错误。
- 的解决方案必须不断更新以跟上在共同项目的变化
有各种溶液中的一个项目，它是使用的好处是：
- 这是比较容易当您可以跟踪对源码执行的问题时进行调试。
另一种方法是让每个解决方案使用他们所需的常见项目的DLL。然后，每个解决方案都可以决定何时更改他们使用的版本。
解决方案中的项目数量不是主要问题。但它会使溶剂的加载和构建变得更慢。我们有超过50个项目的解决方案。
我们有一个包含超过100个项目的“主解决方案”。这花费永远加载VS.2005，直到微软发布Intellisense修复描述here。
我们的自动化“持续集成”构建过程始终构建主解决方案。对于开发，我将“主解决方案”分为包含相关项目子集的较小解决方案。在添加新项目时，保持这种结构需要一些时间，但是非常值得。
我已经与项目发现了多种解决方案，唯一的问题是使用$（PROJECTDIR）而不是$（SolutionDir）在建的规则避免，因为后者取决于项目是如何加载。
Tools for SLN file (Visual Studio Solution file)包含的工具，：
使人们有可能对SLN文件创建过滤器。它的工作方式是 ，当打开过滤器文件时，动态创建一个临时解决方案 。创建的解决方案文件仅包含筛选器中指定的项目 以及这些项目的所有依赖项。这使得拥有包含构建完整系统所需的所有项目的大型解决方案成为可能，但仍然具有在系统的子集上有效工作的可能性。
这消除了开发速度维护子集解决方案文件的大部分成本。
但是你需要问自己，如果你有更多的项目文件，那么你需要，因为结合项目文件可以大大加快编译和加载soltuions。
现在有一个免费的Visual Studio扩展，"Funnel"，通过加载解决方案的预定义子集来解决这个问题。该链接适用于VS2012-VS2015;还有一个在扩展主页上引用的VS2010版本。
您可以设置多个配置文件（即项目组合）。这些文件存储在并行solution.sln.vsext文件中，该文件可以提交并与您的团队共享。尽管VS2015在处理大型，100多种C/C++/C＃项目解决方案方面已经做得更好，但我发现它对排除每次构建解决方案时构建的makefile项目特别有用。
感谢您让我考虑项目中$（SolutionDir）的含义。我们在项目文件中使用$（SolutionName），这需要重新考虑。 – GBegen 2009-11-11 21:52:31