Question

我构建解决方案的时间可能在25％到50％之间，我看到了：

“The operation you requested is taking longer than expected to complete. This dialog will close when the action completes.”

我以我无法描述的方式讨厌这个窗口。它永远不会解决，取消按钮永远不会启用，唯一的解决方法是杀死devenv进程并再次加载我的整个解决方案，完全知道我没有修复任何东西，我同样有责任看到当我尝试构建时也一样。

我的解决方案总共约有60个项目，主要是C＃类库，每个项目都有一些Web应用程序，Web服务和控制台应用程序。但是，即使在卸载大部分（50个）项目的情况下构建一个代码库时，问题仍然存在。

我的问题是输出窗口没有告诉我它冻结的任何地方，我不知道如何确定此锁定的原因。如果我猜测，我会认为这是文件系统中的死锁或其他什么，但我不知道如何证明这一点 - 更不用说如何防止它。

我可以做些什么来诊断并消除我的解决方案，以便我再也看不到它？一般来说，如何诊断构建期间出现的问题？

Answer 1

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

使用ProcMon我可以通过devenv.exe在/ packages /文件夹上看到300万+文件操作，当我构建这个项目时（并会继续一段时间后）！构建的第一步，你可以看到它正在检查每个包，看它是否需要进行包恢复（它没有）

由于我倾向于将NuGet归咎于一切，我禁用了Nuget Package Restore＆＃34;允许NuGet下载丢失的包＆＃34; Visual Studio下的复选框 - ＆gt;选项 - ＆gt; Nuget包管理器 - ＆gt;常规。 令我高兴的是，构建非常快。总计5秒！

事实证明我们已经在启用构建时启用了包恢复（我认为默认情况下现在在VS中启用）并且我们还将包检入源代码控制中。这似乎导致TFS以某种方式颠簸...检查恢复包必须触发TFS进行一些源控制操作检查。

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

更新：

使用SccNumberOfProjects = 53在Sln上的Localhost“Rebuild All”正在以7:05拍摄2分钟的视觉工作室冻结/无响应

在2核心i5上下降到4:14，没有冻结
在4核i7上下到2:44

另外：这是在一台配有各种文件监视器安全工具的计算机上，可能不会为整个过程增加任何速度......并且可能要归咎于此。

Answer 2

我已经看到，当MSBuild在诊断开关打开的情况下运行时，会发生这种情况。在Visual Studio中，转到工具/选项/项目＆amp;解决方案/构建并运行，然后检查MSBuild项目构建输出详细程度值。如果未设置为Minimal，请尝试设置为minimal，并查看您的构建是否能够完成。

Answer 3

似乎像管理员一样运行Visual Studio解决了我的问题！（总是以管理员身份运行程序，请参阅How to Run Visual Studio as Administrator by default）

Answer 4

在我的情况下，设置“并行项目构建的最大数量”为1种有帮助（即从清洁状态构建项目导致1分钟冻结，然后正常构建，并且每个后续构建工作正常）。

可以在Tool -> Options -> Projects and Solutions -> Build and Run。

中设置上述设置

Answer 5

我发现Visual Studio在构建大型项目时非常重要。原来是ReSharper。关闭后：工具 - ＆gt;选项 - ＆gt; ReSharper - ＆gt;暂停现在，一切都没有问题（即使是非常大的解决方案，100多个项目）

Answer 6

当我尝试我的方法时，我没有尝试上述任何解决方案 - 一切都恢复了。

我的步骤如下：

关闭VS
删除 .vs 文件夹
打开我的解决方案
清洁解决方案OK
构建解决方案OK
可选重建 OK

Answer 7

有人建议Microsoft Connect建模项目负责冻结。我从我们的解决方案中删除了一个建模项目，从那时起（大约一周）没有冻结。

Answer 8

VS2019也向我展示了这个问题，就我而言，问题是由于存储在网络共享上的依赖性所致。我有一种预感，Windows Defender防病毒软件正在扫描网络共享中的许多额外内容，这些内容只有在连接到相当慢的VPN时才能访问。

Answer 9

对我来说，问题是在构建（AutoT4）上自动运行T4模板的扩展。使用EF解决方案时禁用它可以解决问题。

Answer 10

我将VS 2008开发平台从Windows 7迁移到Windows 10，遇到了每次我尝试构建大型项目时Visual Studio都会挂断的情况。我必须构建项目，然后使用任务管理器杀死VS然后重新启动。不用说，这使得调试真的很难！无论如何，问题在于，在转向Win 10时，VS不再以管理员身份运行（也许Win 10更特别关于权限）。更改属性以便程序以管理员身份运行解决了问题。（IngoB - 我没有足够的状态对您的帖子发表评论，但感谢您指出这一点！）

Answer 11

只需使用管理员模式尝试以下命令即可。在运行此命令之前，请确保关闭所有VS实例。

struct Alert {
    static let alert = "Alert"
    static let info  = "Information"
} 

func information(message : String) {
    AskConfirmation(type : Alert.info , title: "Information", message: message, completion: { (bool) in
        self.dismiss(animated: true, completion: nil)
    })
}

注意：devenv位于C：\ Program Files（x86）\ Microsoft Visual Studio 14.0 \ Common7 \ IDE

Answer 12

除了解决（或几乎解决）构建问题的felickz's answer之外：

除了构建期间的问题，我还遇到了包管理控制台的问题。花了大约一分钟等待它。使用procmon我发现每次打开这个窗口时都会解析NuGet存储库文件夹（非常聪明，微软！）。此文件夹中有大约1000个包。从上面的文件夹中删除所有内容后，性能问题被删除。

请注意，我的回答与VS 2015（可能在下面）有关。我没有测试过，但怀疑VS 2017应该没问题。

Answer 13

对我来说，这与自动运行的npm软件包安装有关。我转到工具>选项>项目和解决方案>外部Web工具，然后取消选中所有外部工具并重新启动VS。之后，我得以再次构建它。我知道我需要检查它们，但我需要弄清楚是什么触发了它们，以及此解决方案文件出了什么问题。

Answer 14

Visual Studio 2017

从安装中删除Anaconda3可以对其进行修复。在procmon中，我看到成千上万的调用从msbuild生成的数百个Powershell实例中查找Anaconda3文件夹中的文件。

Answer 15

我遇到这个问题是因为还原 nuget 包时出现问题。 packages.config 文件中有重复的条目。构建将永远挂起，而不是将其报告为错误。

直到我尝试通过菜单中的“管理 Nuget 包...”选项恢复 nuget 包后，我才发现问题。删除重复项后，构建正确完成。

Visual Studio在构建期间不断挂起

15 个答案: