在我构建解决方案的 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) 项目已卸载时，问题仍然存在。
我的问题是输出窗口在卡住时没有告诉我任何信息，而且我不知道如何确定此锁定的原因。如果我猜测，我会假设这是文件系统中的死锁或其他什么，但我不知道如何证明这一点——更不用说如何防止它了。
我可以做些什么来诊断并从我的解决方案中消除它，这样我就再也看不到它了？一般来说，如何诊断构建过程中出现的问题？
最佳答案
有类似的问题，VS 会挂起 45 秒左右，然后构建 4 秒并完成。 45 秒的挂起不会对 GUI 产生任何输出，VS 会挂起。
使用 ProcMon，当我构建这个项目时，我可以通过 devenv.exe 在/packages/文件夹上看到超过 300 万个文件操作(并且会在一段时间后继续)!!构建的第一步您可以看到它正在检查每个 PACKAGE 以查看它是否需要进行包还原(它不需要)。
由于我倾向于将所有事情都归咎于 NuGet，因此我禁用了 Visual Studio -> 选项 -> Nuget 包管理器 -> 常规 下的 NuGet 包还原“允许 NuGet 下载丢失的包”复选框。 令我高兴的是，构建速度非常快。总共 5 秒!
事实证明，我们在启用构建时启用了包还原(我认为现在在 VS 中默认启用)并且我们还将包 checkin 源代码管理。似乎这会导致 TFS 以某种方式颠簸...检查恢复包必须触发 TFS 进行一些源代码控制操作检查。
仅供引用，这是 VS2013 UPDATE 4 - Nuget 版本:2.8.50926.663，在 NumberOfProjects = 38 的 sln 上，但我可以重新创建这个挂起，只需构建一个具有 2 个依赖项的 csproj。
更新:
在 SccNumberOfProjects = 53 的 Sln 上，本地主机“全部重建”花费了 7:05，Visual Studio 卡住/无响应 2 分钟
另外:这是在一台带有各种文件观察安全工具的机器上，可能不会为整个过程增加任何速度......并且可能是罪魁祸首。
2021 年更新: 如果您正在寻找一种范式转变，新的 SDK style csproj format (见 migration tool)+ nuget PackageReference使更新几乎是即时的(对于上述场景中的相同项目20 秒) - 强烈建议您升级任何旧项目。 ** 已知的不兼容性 - 网站包引用不支持通过 nuget (checkout LibMan) 进行的静态文件引用
https://stackoverflow.com/questions/19015305/