logo标签列表

在Visual Studio 9解决方案中的项目数量是否会影响解决方案的加载和构建时间？

visual-studio-2008projects-and-solutionsbuild-time
8

我特别关心解决方案的加载时间和构建时间 - 较少的解决方案是否意味着更好的性能？

请注意，我不是在谈论构建应用程序的性能。

在处理较少的项目时，加载时间和构建时间是否更加高效？

作为参考，我们的Visual Studio解决方案中有50-60个项目。

哪个版本的Visual Studio？所有版本都有区别。 - Philippe F
1
nDepends 可以让你检查命名空间之间的“调用”关系，因此你可以在不涉及大量项目的情况下强制执行代码设计规则。 - Ian Ringrose
10个回答
13
以下是内容的翻译：

（我特别关注解决方案的加载时间和构建时间 - 较少的解决方案是否意味着更好的性能？）

这里是 Patrick Smacchia 的相关主题，描述拥有少量程序集（此后是少量项目）的好处。他确切地讨论了程序集数量如何影响构建时间和其他因素。

我鼓励您阅读Patrick的博客。他有很多关于代码组件化的文章。

.NET程序集分区建议

从NUnit代码库中学到的经验教训

如何将现有代码组件化的提示

根据我的个人经验，拥有几十个项目的解决方案非常困难。在我看来，超过10个项目会导致明显的维护问题，并影响您的生产力。

4

这取决于你的项目，大多数情况下我会处理10-15个项目。

我通常涉及以下项目：

  • 基础项目，包括异常处理
  • 业务逻辑
  • 数据访问层 - 存储库
  • WebForms或WinForms或WPF用户界面

其中一些我会分成3-4个其他项目。我也会有NUnit测试项目。

3

对我来说，50-60个项目好像还挺多的。我发现，在很多项目中，打开Visual Studio可能需要很长时间。如果您更改了许多其他项目依赖的项目，构建时间可能会很糟糕，但我不知道在每个有20个类的10个项目和每个有2个项目的100个项目之间，这方面有何不同。(换句话说，我不确定每个项目构建时的开销是多少)即使您什么也没有改变，每个项目都必须检测是否需要重新构建任何内容 - 我无法想象这是免费的，但是如果没有用您自己的代码尝试，很难给出更具体的答案。

我曾在一些公司工作过，每个公司都有一堆只有几个类的项目 - 这些类可以很容易地合并成一个项目。从我的经验来看，这样做还有维护/可管理性方面的好处。(当然不要胡乱合并 - 要明智地处理)

如果您实际上拥有大小合理的项目，只是有很多项目，请考虑分割解决方案(如果可能的话)。如果它们都是微小的项目，请考虑将其中一些组合起来。如果您不需要等待Visual Studio (打开/构建)，则不必太担心。

3

在解决方案中有太多项目是一个不好的想法，它会影响构建时间。请参见this article，该文章比较了几种构建工具的构建时间。根据文章，即使项目不是构建的一部分，Visual Studio每个项目需要2秒钟。

这也符合我的经验，Visual Studio是可用的最慢的构建工具之一。在Visual Studio 6和2006之间，我的构建时间从一分钟增加到了五分钟，对于一个相对简单的C项目而言。

大约有50,000行代码，每个文件大约有2-300行左右。 - Philippe F
3
迟来的回答，但是到目前为止，没有任何答案提到了构建配置。 你可以在解决方案中拥有很多项目，而不是每次运行都构建所有项目。点击 Debug/Release 组合框并创建一个新的构建配置 - 在那里，你可以决定你想要构建哪些项目或不构建。

为什么这样做？我这样做是为了随意“转到定义”，以及可以快速地将项目添加到我的构建中，而不必经历整个添加项目的痛苦。
此外，请注意，如果您有解决方案文件夹，您可以右键单击文件夹并进行构建，这将构建文件夹中的所有项目。
我也是这样做的。我们的解决方案不是很大（10个项目），但构建需要很长时间，有时候Visual Studio似乎很渴望重新构建那些实际上没有改变的项目。因此，我有一个“Web Debug”配置，大部分时间都使用它，只构建我们的Web和Data项目。 - Coxy
哦，我忘了提到关于VS每个项目构建至少需要2秒的评论，无论它是否是最新的，这似乎不适用于关闭该项目的配置，在我的经验中。 - Coxy
1

当你创建许多小项目时，我看到的问题有：

1/ 封装：你想在两个项目之间共享的类、方法或属性必须是公共的，因此可以从任何地方访问。你拥有的项目越多，泄露一些秘密的可能性就越大...

2/ 程序集总数：正如Aku所写，较少的项目意味着较少的程序集。由于每个项目都会本地复制它们使用的程序集，你的文件夹中可能会有 (n * (n - 1)) / 2 个程序集副本（49 个程序集 1 的副本，48 个程序集 2 的副本，...）。对于 50 个项目，这是 1176 个文件！=> 好吧，你可能只有很少（200？），但仍足以在某些地方过时一个或两个副本...

1

我在一个大量项目的项目上工作，大约有50-60个，在开发人员的懒惰/健忘问题与相关问题相比，我发现长时间的加载时间是可以接受的。

许多项目依赖于基础库，因此需要在更改基础库时重新构建。由于项目可以在任何给定时间处于某种变化状态，因此仅让开发人员在子集上工作意味着如果他们懒惰，当从CM工具接收到更新时，他们将不会重新构建整个应用程序。然后他们可能会花费大量时间尝试修复事情并意识到为什么事情出错了。如果整个依赖树被VS知晓并且可以通过快速构建所有内容来使其正常工作，则可以解决这一切。

我意识到优秀的开发人员会默认了解这一点并执行它，但并非每个人都很好，并且有时即使是伟大的人也会失误。

0
在我看来，这只是个人组织和顺序的问题。如果你感觉有很多项目在某种程度上彼此相连，并且它们都属于同一个解决方案，那么你可以这样做。我认为你只需要考虑是否真的需要所有这些项目。不存在所谓的每个解决方案的最大项目数的神奇数字。
0

我通常遵循的一般做法是每个解决方案包含4-5个项目。

  • 业务逻辑
  • 通信层（与服务器相关）
  • 用户界面
  • 测试项目，用于利用/测试其他三个项目

这通常符合我们的风格和实施方式。如果必要，我们也可以在其中包括其他内容，但这些情况对我们来说并不像这四个那样普遍。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接