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

【问题标题】：Should a Visual Studio project be contained in more than one solution?一个 Visual Studio 项目是否应该包含在多个解决方案中？
【发布时间】：2009-11-01 19:27:00
【问题描述】：

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

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

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

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

常见项目的解决方案通常过于庞大，包含当前正在开发的产品所需的几个项目，通常还有很多手头的开发工作不需要的项目。它们只是被归为一种包罗万象的解决方案，涵盖了只是松散相关的项目。由于编译了不需要的代码，这会导致构建时间延长。
在我们试图解决上述胖解决方案的地方，我们经常会得到一个只包含一个项目的过于精简的解决方案。这些中的每一个都需要在解决方案间依赖管理系统中进行额外配置。随着多个 Visual Studio 实例的启动，这也会增加构建时间。

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

单个解决方案中的大量项目是否会对 Visual Studio 2005（我们当前的开发平台）造成任何稳定性问题？它在 VS 2008 或 VS 2010 中会变得更好吗？
如果一个项目包含在多个解决方案中，如果修改项目配置（例如添加新配置），如何管理对多个解决方案的影响？

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

【问题讨论】：

标签： visual-studio projects-and-solutions

【解决方案1】：

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

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

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

编辑

要回答您问题的最后一部分（因为 SO 在您编辑答案时将问题带走！），VS2005 中解决方案的唯一问题是其中有很多项目非常慢。 VS2008 在加载大型解决方案时要快得多，但主要的问题是解决方案中的项目越多，构建所需的时间就越长（即使它只是跳过不支持的项目） t需要构建，需要很长时间）

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

【讨论】：

【解决方案2】：

在多个解决方案中拥有一个项目的主要问题是：

如果您在项目中进行更改，可能会在使用它的另一个解决方案中导致编译错误。
解决方案必须不断更新，以跟上常见项目的变化

在使用的每个解决方案中都有一个项目的好处是：

当您可以将问题解决到源代码时，更容易调试。

另一种方法是让每个解决方案都使用他们需要的常见项目的 dll。然后每个解决方案可以决定何时更改他们使用的版本。

解决方案中的项目数量不是主要问题。但这会使解决方案的加载和构建速度变慢。我们有超过 50 个项目的解决方案。

【讨论】：

【解决方案3】：

我也在一个环境中工作，该环境有许多用于多个可交付成果的常见项目。我们的政策是每个可交付应用程序一个解决方案。因此，一个通用项目可能包含在多个解决方案中。这对我们来说效果很好。公共项目虽然包含在单独的解决方案中，但都映射到相同的源代码存储库位置。因此，如果更改公共代码，所有包含的应用程序都会受到影响。我们的持续集成系统用于检查其他应用程序不会因更改公共代码而中断。

在 VS 解决方案中拥有的项目越多，加载所需的时间就越长，而且在单个解决方案中管理不同的构建配置和依赖项听起来很复杂。

【讨论】：

【解决方案4】：

我们有一个包含 100 多个项目的“主解决方案”。这在 VS.2005 中加载需要很长时间，直到 Microsoft 发布了 Intellisense 修复程序，描述为 here。

我们的自动化“持续集成”构建过程始终构建主解决方案。对于开发，我将“主解决方案”划分为包含相关项目子集的较小解决方案。在添加新项目时维护这种结构需要一些时间，但非常值得。

我在多个解决方案中的项目中发现的唯一问题是通过在构建规则中使用 $(ProjectDir) 而不是 $(SolutionDir) 来避免的，因为后者取决于项目的加载方式。

【讨论】：

感谢您让我思考项目中 $(SolutionDir) 的含义。我们在项目文件中使用了 $(SolutionName)，这需要重新考虑。

【解决方案5】：

Tools for SLN file (Visual Studio Solution file) 包含一个工具：

可以为 SLN 文件创建过滤器。它的工作方式是打开过滤器文件时，会创建一个临时解决方案动态的。创建的解决方案文件仅包含以下项目在过滤器中指定，以及这些的所有依赖项项目。这使得拥有一个包含构建完整系统所需的所有项目，但仍有在系统子集上高效工作的可能性。

这消除了维护子集解决方案文件以加快开发速度的大部分成本。

但是您需要问自己是否有更多的项目文件，因为合并项目文件可以大大加快编译和加载解决方案的速度。

【讨论】：

【解决方案6】：

现在有一个免费的 Visual Studio 扩展，"Funnel"，它通过加载解决方案的预定义子集来解决这个问题。该链接适用于VS2012-VS2015；扩展主页上还引用了VS2010版本。

您可以设置多个配置文件（即项目组合）。这些存储在一个并行的 solution.sln.vsext 文件中，该文件可以提交并与您的团队共享。虽然 VS2015 在处理大型 100 多个 C/C++/C# 项目解决方案方面做得更好，但我发现它对于排除每次构建解决方案时都构建的 makefile 项目特别有用。

【讨论】：