Visual Studio Solution中的建议项目数

Question

我们正在开发新的应用程序，其中包括大约30个开发人员使用C＃在MS Visual Studio中开发的30-50个项目。

我正致力于组件化应用程序模块，以支持架构并实现并行工作。

我们争辩说：我们应该有多少解决方案？

有些人声称我们应该有1-2个解决方案，每个解决方案有15-30个项目。有些人声称我们需要每个组件的解决方案，这意味着大约10-12个解决方案，每个解决方案大约有3-6个项目。

我很高兴听到每个方向（或其他方向）的优点/缺点和经验

由于

Answer 1

我在两个极端的产品上工作过：一个在一个解决方案中有大约100个项目，一个有> 20个解决方案，每个包含4-5个项目（测试，业务层，API等）。

每种方法都有其优点和缺点。

单个解决方案在进行更改时非常有用 - 它更容易使用依赖项，并允许重构工具运行良好。但它确实会导致更长的加载时间和更长的构建时间。

多个解决方案可以帮助实现关注点分离，并使构建/加载时间保持在较低水平，并且可能非常适合让多个团队具有更窄的焦点和明确的服务边界。然而，它们在重构方面有很大的缺点，因为许多引用都是文件，而不是项目引用。

也许混合方法的空间大部分都使用较小的解决方案，但是当需要更大规模的更改时，创建包含所有项目的单个项目。当然，你必须保持两个独立的解决方案......

最后，项目和依赖项的结构将对您组织解决方案的方式产生一些影响。

请记住，从长远来看RAM比程序员时间便宜......

Answer 2

解决方案实际上用于依赖关系管理，因此如果多个方案取决于它，您可以在多个解决方案中使用项目。解决方案的数量应该取决于你的依赖图。

编辑：这意味着你不应该将不相互依赖的项目粘贴到同一个解决方案中，因为它会产生依赖的幻觉，这意味着当两个项目真正独立时，有人可以创建一个真正的依赖。 / p>

Answer 3

我已经开展了近200个项目的解决方案。如果你有足够的RAM，这不是什么大问题。）。

要记住的一件重要事情是，项目是相互依赖的（无论是依赖关系还是引用），它们应该在同一个解决方案中。否则，当不同的项目在不同的解决方案中具有不同的依赖关系时，会出现奇怪的行为。

Answer 4

我们有一个大约有130个项目的解决方案。大约3年前，当我们使用vs.net 2003时，这是一个可怕的问题。有时解决方案和VSS崩溃了。

但是现在使用VS.NET 2005就可以了。只有装载需要很长时间。我的一些同事正在卸载他们不使用的项目。这是加速的另一种选择。

将构建类型更改为发布是另一个问题。但我们现在有MSBuild脚本。我们不再使用VS.NET的版本了。

Answer 5

您想要维护项目引用。如果您可以安全地使用两个或更多彼此依赖的离散项目来解决您的解决方案，那么就这样做吧。如果你不能，那么他们都属于一起。

Answer 6

我认为你不应该夸大你的项目/解决方案的数量。组件化可以  并将重复使用，否则不要组件化！ 它只会降低透明度并增加构建时间。分区也可以使用文件夹或使用逻辑类结构在项目中完成。

Answer 7

我认为解决方案的实际数量并不重要。更重要的是你沿着功能线打破了局面。作为一个愚蠢的，人为的例子，如果你有一些处理与外国网络服务互操作的图书馆，这将是一个解决方案;带有它需要工作的DLL的EXE将是另一个。

Answer 8

在一个解决方案中，只有关于这么多项目的事情是引用和构建顺序开始变得混乱。

作为一般规则，我倾向于减少项目数量（使项目更加通用）并让开发人员共享这些项目的源代码控制，但是通过子命名空间将这些项目中的功能分开。

Answer 9

您应该拥有所需数量。没有硬限制或最佳实践。练习并阅读有关哪些项目和解决方案，然后根据需要做出正确的工程决策。

Answer 10

在其他答案中已经说过，但可能值得再说一遍。

项目依赖性很好，因为如果依赖项有变化，它们可以重建依赖项目。

如果您执行汇编文件依赖，则VS或MSBuild无法知道需要构建一串项目。将会发生的是，在第一次构建时，将重建已更改的项目。如果你已经依赖于构建输出，那么至少在第二次构建时，项目将依赖于构建。但是，你需要一定数量的构建才能到达链的末尾。

对于项目依赖项，它会为您排序。

因此，所使用的答案可以根据需要提供尽可能多的（或很少的）以确保项目依赖性。

如果您的团队被分解为具有更正式的发布机制而不是签入源代码的功能区域，那么将其拆分为这些线路，否则依赖关系图将是您的朋友。

Answer 11

在决定您需要多少项目与解决方案时，您需要解决一些问题：

• 您的应用程序的逻辑层;
• 项目之间的依赖关系;
• 如何构建项目;
• 谁与哪些项目合作;

目前，我们有一个包含70个项目的解决方案。 对于我们的持续集成，我们创建了5个msbuild项目，因此CI不构建我们的开发解决方案。

以前，我们在单独的git存储库中有单独的表示（Web和相关项目）层解决方案。外包和自由网络开发人员使用此解决方案。

Answer 12

我正在使用目前有405个项目的解决方案。在速度非常快的计算机上，这是可行的，但仅适用于当前的Visual Studio 2017或2012。其他版本经常崩溃。