我在 Visual Studio 中进行 PHP 开发，我的解决方案包含 PHP、SSRS 和 SQL Server (SSDT) 的项目。我正在使用 TFS 进行版本控制。所以在我的开发环境中发生了很多可能“出错”的事情。
我遇到了间歇性挂起，通常一个剪辑大约 5 分钟。Visual Studio 给了我等待光标，如果我单击 VS 中的任何位置，窗口就会变暗。然后我只需要等待它。有时我可以结束 devenv.exe 任务，有时需要几分钟才能终止任务。如果我有耐心，我会等待，最终（大约 5 分钟）VS 会恢复活力。即使我终止了进程，我也从未经历过数据丢失、源代码控制问题等。
我保存时有时会发生这种情况。有时当我办理登机手续时。有时我退房的时候。有时当我建立。我一直无法辨别任何类型的行为模式。
我所有的工作站资源都很好——没有 RAM 或 i/o 或网络或 CPU 问题。
我可以做些什么来解决这个问题？我可以在某种日志记录模式下运行 VS，让我可以查明在这些锁定期间需要这么长时间的原因吗？
要在 Visual Studio 中打开日志记录，请运行：devenv.exe /log
我个人会用捷径做到这一点。
考虑删除从持续集成构建中遗留下来的旧 TFS 工作区定义。
我们在大型 Team Foundation Server 项目树中遇到了同样的问题。有时，但并非总是如此，在 Visual Studio 2010 或 Visual Studio 2012 中打开解决方案会完全按照上述方式挂起。VS 2010 最脆弱；VS 2012 似乎不那么容易受到攻击，但它仍然会挂起。
通过监视 TFS Server 机器和底层 SQL Server 机器上的服务器活动，我们能够获得一些线索。某个查询存储过程在 SQL Server 中使用了过多的 CPU 时间。我们将此存储过程名称跟踪到一个 TFS 操作，该操作涉及扫描 TFS 工作区定义以查找其他用户的文件签出。
我们的 TFS 环境已经使用了 3 年多，我们一直在使用持续集成构建定义，使用开发人员工作站的“僵尸军队”作为 TFS 构建代理主机。我们还为主要版本创建新的 TFS 分支。每个分支包含大约 20 个具有自己构建定义的独立 Visual Studio 解决方案。
随着时间的推移，我们在每个开发人员工作站上积累了大约 2,000 个 TFS 工作区定义。我们一次有大约 10 个工作站，它们都有自己的定义。
使用 Visual Studio 命令窗口并以 TFS 管理员身份运行，我们使用此命令来识别由我们的“构建用户”创建的所有工作区：
tf 工作区 /collection:tfservername\collectionname /owner:ourbuilduser >c:\tf_ws_del.bat
然后，我们使用全局替换和 Notepad++ 编辑器宏记录器将每个结果行转换为以下形式：
tf 工作区 /delete /collection:tfservername\collectionname 工作区名;ourbuilduser <c:\yes.txt
其中 C:\yes.txt 包含单行“y”
我们还使用一些人工判断来删除以我们最近的 TFS 分支命名的工作区的删除行。
然后，我们在同一个 Visual Studio 命令窗口中运行该 c:\tfs_ws_del.bat 脚本并耐心等待它完成。
最终结果：我们的 Visual Studio 解决方案打开速度非常快。即使在源代码管理资源管理器中浏览文件夹层次结构也大大加快了速度。
警告：大量工作区的删除操作可能会大量扩展基础 SQL Server 上的 TempDB。与您的 DBA 协调以监控 SQL Server 机器上的空间。通过图形 TFS 管理员控制台工具停止和重新启动 TFS 集合有助于回收部分 TempDB 空间并将其返回到其内部“空闲块”列表。
当调试选项中指定的符号服务器关闭或无法访问时，这似乎也会发生......在这种情况下它实际上不会挂起，但似乎每次文件访问都会超时。
要暂时解决此问题，请取消选中已关闭的符号服务器。