logo标签列表

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

visual-studioprojects-and-solutions
13

注意：这是一个使用C ++、C ++ / CLI和C#的商店，有些产品是三者的组合。

我们目前有一个规则，即一个项目应该有且仅有一个包含解决方案。最初制定此规则是因为Visual Studio的源代码控制插件无法处理包含在多个解决方案中的项目，每当从一个解决方案切换到另一个解决方案时，它总是试图更改源代码控制绑定。

出于其他原因，我们将彻底停止使用源代码控制插件（不放弃源代码控制，只是放弃这个脑残插件）。这重新引发了一个问题，即是否继续限制项目仅包含在一个解决方案中的政策。

我们在库、dll和程序集中有大量的代码，这些代码被多个可交付产品使用，并且我们目前通过一种互相依赖的管理系统来控制这些代码，即如果在最终产品的解决方案中工作，则可以简单地请求构建依赖项解决方案，这将启动其他实例的Visual Studio来构建它们。这个系统有效，但有以下缺点：

  • 常用项目的解决方案通常太厚重，包含当前正在开发的产品所需的一些项目，通常还包含了不需要的大量项目。它们只是被归为一个所谓的万能解决方案，涵盖了仅仅是松散相关的项目。这会导致由于编译不必要的代码而出现扩展的构建时间。
  • 当我们试图解决上述厚重解决方案时，我们通常会留下一个过于轻量化的解决方案，其中只包含一个项目。每个解决方案都需要在互相依赖的管理系统中进行额外的配置。这也可能增加构建时间，因为需要打开多个Visual Studio实例。

我在考虑修改政策，允许一个项目在多个交付产品中被包含在多个解决方案中。我们可以消除解决方案之间的依赖管理，并严重减少解决方案数量（每个产品仅有一个解决方案）。我担心这种重新组织会带来的工作量以及它是否值得这样做。我担心在团队使用一段时间后才能检测到潜在的好处。我也预见到了一些潜在的问题，这才是真正需要回答的问题。

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

对于已经在每个可交付产品中只有一个解决方案，并将共同组件作为包含在多个解决方案中的项目的环境中工作的人：您遇到过这种配置的任何重大缺点吗？

6个回答
9
不要限制解决方案的数量，使用方便的数量即可。例如，我们有一个大型解决方案，构建大约53个项目。它包括安装程序和卸载程序，以便可以通过我们的构建服务器方便地构建它们，但如果我想在这些应用程序上工作，我会将它们加载到它们自己的解决方案中（每个解决方案只有1个项目），而不是浪费所有时间加载其他69个不必要的项目。它们没有任何依赖关系，因此以这种方式做没有任何问题（实际上，它更高效，因为解决方案的加载和构建速度更快）。多个解决方案唯一的注意事项是，在任何情况下都要小心不构建依赖项（例如，如果您不构建库，则需要小心在源代码更改时进行构建，因为它将不再自动为您构建）。
编辑：回答您问题的最后部分（因为SO在您编辑答案时会将问题移走！），VS2005中解决方案的唯一问题是其中有很多项目时非常缓慢。 VS2008在加载大型解决方案时要快得多，但主要问题仍然是项目越多，构建所需的时间就越长（即使只是跳过不需要构建的项目，也需要很长时间）。如果添加新的解决方案配置，则只需创建一个超级解决方案（或保留现有解决方案！），然后在其中进行更改，以便一次应用于所有项目。您仍然需要将该新配置添加到要使用的任何单独解决方案中，但如果它们是单个项目解决方案，则可以将其删除，加载.csproj文件，它将自动重建并包含所有配置。而且，不太可能经常添加新配置。
4
将一个项目放在多个解决方案中存在以下主要问题：
  • 如果您更改项目，可能会导致在使用它的另一个解决方案中出现编译错误。
  • 必须不断更新解决方案以跟上公共项目中的更改。
每个解决方案中都有一个项目的好处是：
  • 当您可以追踪到源代码时，更容易调试问题。
另一种方法是使每个解决方案使用它们所需的公共项目的dll。然后，每个解决方案可以决定何时更改使用的版本。
解决方案中项目的数量并不是主要问题。但是，它会使解决方案加载和构建变慢。我们有超过50个项目的解决方案。
3
我也在一个有许多共同项目的环境中工作，这些项目被用于多个可交付成果。我们的政策是每个可交付应用程序使用一个解决方案。因此，一个公共项目可能包含在多个解决方案中。这对我们来说效果很好。虽然公共项目包含在单独的解决方案中，但它们都映射到相同的源代码存储库位置。因此，如果更改了公共代码，所有包含的应用程序都会受到影响。我们的持续集成系统可以检查其他应用程序是否因为对公共代码的更改而出现故障。
在VS解决方案中拥有更多的项目，加载时间会更长，而且在单个解决方案中管理不同的构建配置和依赖关系听起来很复杂。
3
我们有一个包含100多个项目的“主解决方案”。在VS.2005中加载此解决方案需要很长时间，直到微软发布了Intellisense修复程序，详见这里。
我们的自动化“持续集成”构建过程总是会构建主解决方案。为了开发方便，我将“主解决方案”分成包含相关项目子集的较小解决方案。虽然添加新项目时需要花费一些时间来维护这种结构，但它非常值得。
我发现多个解决方案中的项目唯一的问题可以通过在构建规则中使用$(ProjectDir)而不是$(SolutionDir)来避免，因为后者取决于如何加载项目。
感谢让我思考$(SolutionDir)在项目中的影响。我们在项目文件中使用$(SolutionName)，这需要重新考虑。 - GBegen
2
SLN文件工具（Visual Studio Solution文件）包含一个工具，可以：
创建SLN文件的过滤器。它的工作方式是，在打开筛选文件时，动态创建一个临时解决方案。创建的解决方案文件仅包含指定在筛选器中的项目及其所有依赖项。这使得可能拥有一个包含构建完整系统所需的所有项目的超级解决方案，但仍然有可能高效地处理系统的子集。
这消除了为了开发速度而维护子集解决方案文件的大部分成本。
但是，您需要问自己是否拥有比您需要的更多的项目文件，因为合并项目文件可以大大加快编译和加载解决方案的速度。
1
现在有一个免费的Visual Studio扩展“Funnel”，可以通过加载预定义的解决方案子集来解决这个问题。该链接适用于VS2012-VS2015；扩展主页上也引用了VS2010版本。
您可以设置多个配置文件（即项目组合）。这些文件存储在并行的solution.sln.vsext文件中，并且该文件可以被提交和共享给您的团队。虽然VS2015已经在处理大型、包含100个以上的C/C++/C#项目的解决方案方面变得更加出色，但我发现它特别适用于排除每次构建解决方案时都会构建的makefile项目。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接