visual-studio - 一个 Visual Studio 项目是否应该包含在多个解决方案中？

Question

注意:这适用于使用 C++、C++/CLI 和 C# 工作的商店，其中一些产品作为这三者的组合交付。

我们目前有一个规则，一个项目应该有一个且只有一个包含解决方案。最初设置该规则是因为 Visual Studio 的源代码管理插件无法处理包含在多个解决方案中的项目，在从一种解决方案更改为另一种解决方案时总是试图更改源代码管理绑定(bind)。

由于其他原因，我们将完全停止使用源代码控制插件(不放弃源代码控制，只是脑死插件)。它重新提出了是否继续将项目限制在一个解决方案中的政策的问题。

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

常见项目的解决方案通常过于庞大，包含当前正在开发的产品所需的几个项目，通常还有很多手头的开发工作不需要的项目。它们只是被归为一种包罗万象的解决方案，涵盖了只是松散相关的项目。由于编译了不需要的代码，这会导致构建时间延长。

在我们试图解决上述胖解决方案的地方，我们经常会得到一个只包含一个项目的过于精简的解决方案。这些中的每一个都需要在解决方案间依赖管理系统中进行额外配置。随着多个 Visual Studio 实例的启动，这也会增加构建时间。

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

单个解决方案中的大量项目是否会对 Visual Studio 2005(我们当前的开发平台)造成任何稳定性问题？它在 VS 2008 或 VS 2010 中会变得更好吗？

如果一个项目包含在多个解决方案中，如果修改项目配置(例如添加新配置)，如何管理对多个解决方案的影响？

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

Answer 1

不，尽可能多地使用解决方案。

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

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

编辑

要回答您问题的最后一部分(因为 SO 在您编辑答案时会带走问题!)，VS2005 中解决方案的唯一问题是其中有很多项目非常慢。 VS2008 加载大型解决方案的速度要快得多，但主要的打击是解决方案中的项目越多，构建所需的时间就越长(即使它只是跳过不需要构建的项目，它花费很长时间)

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