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