Visual Studio项目是否应包含在多个解决方案中？

Question

注意:这适用于在C++,C++/CLI和C#中工作的商店,其中一些产品是作为三者的组合交付的.

我们目前有一条规则,即项目应该只有一个包含解决方案.该规则最初是因为Visual Studio的源代码控制插件无法处理多个解决方案中包含的项目,因此在从一个解决方案更改为另一个解决方案时总是尝试更改源代码控制绑定.

出于其他原因,我们将完全停止使用源代码控制插件(不会丢弃源代码控制,只是停止使用脑干插件).它重新提出了是否继续限制只包含一个解决方案的项目的政策的问题.

我们在多个可交付产品所使用的库,dll和程序集中有相当多的代码,我们目前通过一个解决方案间依赖关系管理系统来控制它,如果一个人在最终产品的解决方案中工作,请求构建依赖项解决方案是一件简单的事情,它将启动Visual Studio的其他实例来构建它们.该系统有效,但有以下缺点:

• 常见项目的解决方案通常太胖,包含当前开发的产品所需的一些项目,并且通常还有许多不需要用于手头开发工作的项目.它们只是被归结为一种全面的解决方案,涵盖了仅与松散相关的项目.由于编译了不需要的代码,因此导致构建时间延长.
• 在我们试图解决上述胖解决方案的地方,我们常常只留下一个只包含一个项目的太瘦的解决方案.这些中的每一个都需要在解决方案间依赖性管理系统中的附加配置.随着Visual Studio的多个实例的旋转,这也会增加构建时间.

我正在考虑修改政策,允许多个可交付产品中使用的项目包含在多个解决方案中.我们可以消除解决方案间依赖关系管理并严重减少解决方案的数量(每个产品减少一个).我担心这次重组将需要做多少工作以及是否值得付出努力.在团队使用它一段时间之前,我恐怕甚至无法发现潜在的好处.我还预见到一些潜在的问题,这些都是真正的问题.

• 单个解决方案中的大量项目是否会在Visual Studio 2005(我们当前的开发平台)中出现任何稳定性问题？在VS 2008或VS 2010中它会变得更好吗？
• 如果项目包含在多个解决方案中,如何修改项目配置(例如添加新配置),如何管理多个解决方案的效果？

对于已经在每个可交付产品中使用一个解决方案的环境中工作的任何人,将通用组件作为多个解决方案中包含的项目:您是否遇到过此类配置的任何重大缺陷？

Answer 1

不,使用尽可能多的解决方案.

例如,我们有一个大型解决方案,可构建约53个项目.它包括一个安装程序和卸载程序,以便它们可以由我们的构建服务器方便地构建,但如果我想处理这些应用程序,我将它们加载到自己的解决方案中(每个项目1个项目),而不是在所有时间加载其他69个其他不必要的项目 它们对其他项目没有任何依赖关系,所以这样做完全没有问题(事实上,随着解决方案加载和构建速度更快,效率更高)

多个解决方案的唯一警告是,在不构建依赖项的任何情况下都必须小心(例如,如果您不构建库,那么您需要注意每当源代码构建时它都会构建它会改变,因为它将不再为你自动构建)

编辑

要回答你问题的最后一部分(因为在你编辑答案时SO会把问题拿走!),VS2005中解决方案的唯一问题是它中的很多项目都很慢.VS2008 加载大型解决方案的速度要快得多,但主要的问题是解决方案中的项目越多,构建所需的时间就越长(即使它只是跳过不需要构建的项目,它也是如此)需要很长的时间)

如果你添加一个新的解决方案配置,那么只需制作一个超级解决方案(或者只保留现有的解决方案!),然后对其进行更改,以便一次性应用于所有项目.您仍然需要将新配置添加到您想要使用的任何单独的解决方案中,但如果它们是单项目解决方案,您可以删除它们,加载.csproj并且它将自动重建所有配置它.添加新配置可能不会经常发生.