24

我们有一个中等规模的解决方案，大约有 20 个项目。在其中一个中，我有我的商业实体。在编译任何项目时，Visual Studio 会在这个 BusinessEntities 项目上等待并挂起大约一分半钟。

我在 SharpDevelop 中尝试了我们的解决方案，它在 18 秒内编译了我们的完整解决方案。与 MSBuild 类似的时间。

我的猜测是 VS 试图找出项目是否需要编译，但是这个过程比实际执行编译慢了大约 15 倍！

我不能切换到伟大的sharpdevelop，它缺少我们调试场景的一些小但必不可少的要求。

我可以阻止VS检查这个项目，并让它在没有这样检查的情况下编译项目，就像sharpdevelop一样？

我已经知道在配置管理中取消选中项目以防止构建一些项目，但是我的开发人员会忘记他们需要在更新到最新源后编译这个项目，并且他们面临着对他们来说似乎很奇怪的问题。

编辑：调查的有趣结果：延迟仅发生在其中一个项目上。在配置管理器中，我取消选中所有项目，然后单独编译每个项目。所有项目在几秒钟内编译！！关键是：如果该特殊项目是直接构建的，则在几秒钟内编译，如果它正在构建（或跳过，因为它是最新的）作为构建另一个依赖它的项目的结果，VS挂起大约一分半钟，然后决定编译它（或跳过它）。我的结论：Visual Studio 正在检查是否有任何文件被更改，但由于某些原因，对于这个特殊项目来说效率极低！！

4

11 回答 11

10

我会去Tools -> Options -> Projects and Solutions -> Build and Run然后将“MSBuild项目构建[输出|构建日志]详细程度”更改为诊断。在那个级别，它将包括可以帮助您追踪问题的时间安排。

于 2012-08-26T05:19:35.850 回答
4

我们在 Visual Studio 2013 中运行的 ASP.NET MVC Web 项目遇到了同样的问题。我们构建了项目，大约一分钟左右没有任何反应，然后输出窗口显示我们正在编译。

这是修复它的原因...在文本编辑器中打开.csproj 文件并将 MvcBuildViews 设置为 false：

<MvcBuildViews>false</MvcBuildViews>

我不得不使用 sysinternals 进程监视器来解决这个问题，但这显然是我遇到这种情况的原因。该网站现在在不到 5 秒的时间内完成编译，而之前则需要一分钟。在那一刻，Asp.net 编译过程将文件和目录放入 Temporary Asp.net Files 文件夹。

警告：如果您设置此选项，您将不再预编译视图，因此您将无法在构建时查看视图中的语法错误。

于 2015-06-02T17:11:01.187 回答
3

为了当前编译项目的利益，您可能正在遭受 VS 检查其他新构建的程序集的痛苦。

构建程序集时，VS 将检查目标程序集的引用，如果它们是新构建的或新版本，可能包括实际将它们加载到 .Net 域中，它承担着加载程序集的所有负担，就好像你是要去运行它。随着重建越来越多的项目，构建可能会逐渐变慢。当一个组件更新时，其他组件会做更多的工作。这是一种可能的解释，为什么单独建造，与已经建造的，与建造干净的，都有看似相关的不同结果。它真的是其他人改变了，而不是关于正在编译的那个。

VS 将“标记”所引用程序集的最后一个“内部”构建号，并查看所引用程序集在其构建过程中是否实际发生了变化。如果没有什么不同，就会跳过大量工作。是的，有您无法控制的内部装配版本号。这很可能不是由于实际的 c# 编译器或其工作或任何后编译的原因，而是大多数情况下所需的预编译步骤。

您可以使用几种面向参考的设置，根据您的开发、测试或部署需求，功能差异可能无关紧要，但可能会深刻影响 VS 的行为方式和构建过程所需的时间。

转到解决方案资源管理器中某个项目的引用：

1）点击参考

2）如果不是（不是属性页或属性管理器）打开属性窗格

3) 查看“Copy Local”、“Embed Interop Types”、“Reference Output Assembly”；这些可能非常适用，并且无论如何都可能是值得了解的好东西。我强烈建议在 MSDN 上查找他们所做的事情。“参考输出程序集”可能会或可能不会显示在列表中。

4）卸载项目，在VS中将.proj文件编辑为文本。在 XML 中查找程序集引用并查找“私有”。这意味着从引用程序集的角度来看，是否将引用的程序集视为私有程序集，而不是共享程序集。这是一种冗长的说法，该组件是否会与其他组件一起部署为一个单元。这对于减轻负担非常重要。背景：http: //msdn.microsoft.com/en-us/magazine/cc164080.aspx

所以这里的基本想法是，您希望将所有这些配置为最便宜的，无论是在构建期间还是在部署之后。如果您将它们一起构建，那么例如您可能真的不需要“复制本地”。在不了解您的需求的情况下，我不想多说您应该如何配置它们，但是阅读一些关于每个的好段落是一件非常好的事情。然而，这变得非常棘手，因为您还会影响 VS 在重新构建引用的解决方案时是否会使用陈旧的旧解决方案。作为进一步的示例，说明阅读这些内容很好，Copy Local可以使用本地副本，即使它已经过时，所以拥有这一套可能是双重坏的。请记住，目前的目标是降低 VS 加载新构建的程序集 jsut 以编译其他程序集的负担。

最后，就目前而言，我可以轻松地说，仅挂 1.5 分钟就很幸运了。由于这样的事情，有些人的构建时间要差得多；）

于 2012-09-01T04:57:16.277 回答
1

听起来很傻，但首先删除所有断点。它极大地加快了我的预构建检查 - 但仍然不知道为什么。

于 2012-08-25T13:52:17.940 回答
1

一些未提及的故障排除思路：

  • 清洁解决方案？

  • 删除 Obj 和 Bin 文件夹？仅供参考，Clean 和 Rebuild 都不会删除非构建文件，例如在预构建命令期间复制的文件。

  • 关闭 VS 扫描外部文件。选项>工具>环境>文档>检测文件何时在环境之外更改？

  • 回滚 SVN 历史以确认它何时开始发生？发生了什么变化？如果第 1 天的项目文件花费相同的时间，请重新创建项目，添加所有文件并构建。

否则，您能否运行 Process Monitor 并让我们知道 Visual Studio 在准备构建阶段正在做什么？

于 2012-08-27T00:54:39.373 回答
1

根据提供的（有限的）信息，一种可能性是项目文件中指定的预构建操作可能编译速度很慢。

于 2012-08-29T21:14:34.457 回答
1

尝试按照此处所述禁用平台验证任务。

于 2012-08-31T03:40:41.353 回答
1

如果您的单个项目正在正确编译，那么您所能做的就是通过在配置中明确设置依赖项目来更改编译顺序。

尝试可视化您的项目依赖层次结构并设置依赖项目。例如，如果您的业务实体项目在每个项目中都被引用，那么在每个项目的配置中，必须选择该项目作为依赖项。

当未设置显式构建顺序时，Visual Studio 正在分析项目以创建构建项目的顺序。设置显式依赖项目 wiki 使 Visual Studio 跳过此步骤并使用您提供的顺序。

于 2012-08-31T07:41:04.807 回答
1

由于单个项目的延迟如此之大，而且似乎没有其他途径可以提供理由，我会尝试构建该特定项目，同时从 sysinternals 运行procmon并过滤掉所有成功消息。您也可以将其范围缩小到文件系统操作。根据您的描述，我可能猜到文件被事件收集或工作流管理流程服务等外部源锁定。

其他要考虑的事情是这是否是一个完全干净的构建机器，或者它是否也被用来测试构建？如果是这样，是否有人将 IIS 应用程序路径直接映射到项目或将其注册为服务位置？

如果您运行 procmon 并且没有看到明显的锁定或冲突，我将创建一个全新的解决方案和项目并复制文件以查看该项目是否也有相同的延迟。如果它确实有相同的延迟，我会创建一个相同类型但通用数据（基本上是空的）的示例项目，看看它是否也很慢。如果具有相同文件的新项目构建良好，则可以比较目录以查看导致问题的差异（可能是配置或项目设置）。

于 2012-09-01T02:27:44.640 回答
1

对我来说，按照此处的说明彻底禁用代码分析器会有所帮助： https ://docs.microsoft.com/en-us/visualstudio/code-quality/disable-code-analysis?view=vs-2019#net-framework-projects 。

我以为我的代码分析器已经关闭，但添加额外的 xml 有帮助。

感谢 Kaleb 建议将“MSBuild 项目构建 [输出|构建日志] 详细程度”设置为诊断。第一条消息用了 10 多秒才显示出来：

属性重新分配：C:\myProjectDirectory\packages\Microsoft.NetFramework.Analyzers.2.9.3\build\Microsoft 中的 $(Features)=";flow-analysis;flow-analysis"（上一个值：";flow-analysis"） .NetFramework.Analyzers.props (32,5)

这导致我使用代码分析器。

于 2019-10-31T23:54:42.790 回答
1

以防万一其他人遇到这个问题：

在我的情况下，延迟是由“其他包含目录”中的无效路径条目引起的，该条目引用了不可访问的 UNC 位置。

一旦纠正了这一点，延迟就消失了。

于 2020-03-28T20:29:43.643 回答