VisualStudio 在构建期间不断挂起

在我构建解决方案的25% 到50% 的时间里，我看到了这样的情况:

“ 请求的操作花费的时间比预期的要长。此对话框将在操作完成时关闭。”

我讨厌这扇窗户，我无法形容。它从来没有解决，取消按钮从来没有启用，唯一的补救办法是关闭 devenv 进程，再次加载我的整个解决方案，充分知道我没有修复任何东西，我同样有可能看到同样的事情，当我尝试我的构建。

我的解决方案总共有大约60个项目，其中大部分是 C # 类库，每个项目都有一些 Web 应用程序、 Web 服务和控制台应用程序。然而，即使在构建代码库的一部分时卸载了大部分项目(50个) ，问题仍然存在。

我的问题是，输出窗口在它冻结的时候没有告诉我任何东西，我不知道如何确定这种锁定的原因。如果要我猜测，我会假设这是文件系统中的死锁之类的，但我不知道如何证明这一点——更不用说如何防止了。

我能做些什么来诊断并从我的解决方案中消除这种情况，以便我永远不会再看到它？通常，我如何诊断在构建过程中发生的问题？

75165 次浏览
小开

有人建议 微软连接的建模项目是负责冻结。我从我们的解决方案中删除了一个建模项目，并且从那时起(大约一个星期)就没有经历过冻结。

小开

我曾经在大型项目中看到过这种情况，当 MSBuild 运行时，诊断开关是打开的。在 VisualStudio 中，转到 Tools/Options/Projects & Solutions/Build And Run，然后检查 MSBuild 项目 Build 输出详细值。如果它没有设置为最小，尝试设置为最小，看看您的构建是否能够完成。

小开

有一个类似的问题，VS 将挂起45秒左右，然后构建4秒并完成。挂起的45秒不会产生任何 GUI 输出，VS 会挂起。

通过使用 ProcMon，当我构建这个项目时，我可以通过 devenv.exe 在/package/文件夹上看到300多万个文件操作(之后还会继续一段时间) ! ！在构建的第一步，您可以看到它正在检查每个程序包，以查看是否需要执行包恢复(它不需要)。

因为我倾向于把一切都归咎于 NuGet，所以我在 Visual Studio-> Options-> Nuget Package Manager-> General下禁用了 NuGet 软件包恢复“允许 NuGet 下载丢失的软件包”复选框。令我高兴的是，构建非常快。总共5秒！

原来我们在启用构建时启用了包恢复(我认为这在 VS 中是默认启用的) ，而且我们还将包签入了源代码控制。似乎这会导致 TFS 以某种方式跳动... ... 检查是否还原包必须触发 TFS 执行一些源代码控制操作检查。

仅供参考，这是 VS2013 UPDATE 4-Nuget 版本: 2.8.50926.663，在一个 NumberOfProjects = 38的 sln 上，但是我可以重新创建这个挂起，只需构建一个具有2个依赖项的 csproj。

更新:

本地主机“ Rebuild All”在 Sln 上使用 SccNumberOfProjects = 53在7:05进行，2分钟的视觉工作室被冻结/无响应

  • 降到4点14分，在没有冰冻的2核 i5上
  • 4核 i7降到2分44秒

此外: 这是在一台机器上的各种文件监视器安全工具，可能没有增加任何速度，这一整个过程... 也可能是责任。

2021年更新: 如果您正在寻找一个范式转变，新的 SDK 样式 csproj 格式(参见 移动工具) + Nuget PackageReference使更新几乎即时(对于上述场景中的相同项目，< 20秒)-强烈建议您升级任何遗留项目。 * * 已知的不兼容性-网站包引用不支持通过 nuget 的静态文件引用(签出 LibMan)

小开

对我来说，这个问题是一个自动运行 T4模板的扩展(AutoT4)。在使用 EF 解决方案时禁用它解决了这个问题。

小开

在我的例子中，将“最大并行项目构建数量”设置为1有一定帮助(例如，从干净状态构建项目会导致1分钟的冻结，然后是正常构建，并且随后的每个构建都能正常工作)。

上述设置可以在 Tool -> Options -> Projects and Solutions -> Build and Run中设置。

小开

似乎以管理员身份运行 VisualStudio 为我解决了这个问题！(有关始终以管理员身份运行程序的信息，请参见 如何默认以管理员身份运行 VisualStudio)

小开

我将我的 VS 2008开发平台从 Windows7移到 Windows10，遇到了这样一种情况: 每次我试图构建一个大型项目时，Visual Studio 都会挂断。我必须构建这个项目，然后使用任务管理器杀死 VS，然后重新启动。不用说，这使得调试非常困难！无论如何，问题是在转移到 Win 10时，VS 不再以管理员的身份运行(也许 Win 10更注重特权)。更改属性以使程序以管理员身份运行解决了问题。(IngoB ——我没有足够的状态来评论你的帖子，但是谢谢你指出这一点!)

小开

我发现 VisualStudio 在构建大型项目方面有很多优势。原来是 ReSharper。关闭之后: 工具-> 选项-> ReSharper-> 暂停现在，一切构建良好没有问题(即使在非常大的解决方案，100 + 项目)

小开

只需尝试下面的命令与管理模式。在运行此命令之前，请确保关闭所有 VS 实例。

devenv /resetuserdata

注意: devenv 位于 C: Program Files (x86) Microsoft Visual Studio 14.0 Common7 IDE

小开

除了解决(或几乎解决)这个构建问题的 Felickz 的回答:

除了构建过程中的问题之外，我还遇到了包管理控制台的问题。等了大概一分钟。使用 procmon，我发现每次打开这个窗口时都会解析 NuGet 存储库文件夹(非常聪明，Microsoft!).这个文件夹里大约有1000个包。从上面的文件夹中删除所有内容后，性能问题消失了。

请注意，我的答案与 VS 2015有关(可能在下面)。我没有测试，但怀疑在 VS 2017它应该没问题。

小开

对我来说，这是一些与 npm 包安装，自动运行。我去工具 > 选项 > 项目和解决方案 > 外部网络工具，取消检查所有外部工具，重新启动 VS 之后，我能够再次构建它。我知道我需要检查它们，但我需要找出是什么触发了它们，以及这个解决方案文件出了什么问题。

小开

Visual Studio 2017

从安装中删除 Anaconda3修复了它。在 procmon 中，我看到成千上万的调用在 Anaconda3文件夹中查找由 msbuild 产生的数百个 Powershell 实例中的文件。

小开

对我来说，VS2019也展示了这个问题，在我的案例中，这个问题是由于存储在网络共享上的依赖性造成的。我有一种预感，Windows Defender 杀毒软件正在扫描网络共享中的大量额外内容，这些内容只有连接到速度相当慢的虚拟专用网(vPN)时才能访问。

小开

我没有尝试上述任何一种方法，因为当我尝试我的方法时，一切又恢复正常了。

我的步骤如下:

  1. 关闭 VS
  2. 删除.vs 文件夹
  3. 打开我的解决方案
  4. 清洁溶液，好的
  5. 构建解决方案 OK
  6. 可选重建 OK
小开

我之所以有这个问题，是因为一个修复 Nuget 软件包的问题。在 packages.config文件中有一个重复的条目。构建将永远挂起，而不是将其报告为错误。

直到我尝试通过菜单中的“ ManageNugetPackages...”选项恢复 Nuget 包，我才发现问题。删除副本之后，构建就正常完成了。


提交答案