Visual Studio 2013 + TFS = 慢

本文介绍了Visual Studio 2013 + TFS = 慢的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

限时送ChatGPT账号..

我使用的是最近重新安装的带有 SSD 的笔记本电脑.我正在使用带有 TFS 的 Visual Studio 2013.

I am using a recently re-installed laptop with SSD. I am using Visual Studio 2013 with TFS.

我的问题是，当我开始和结束合并或比较时，我需要等待大约 20 - 25 秒.结束 Web 调试会话的等待时间也是 30 秒左右.

My problem is that I need to wait for about 20 - 25 seconds when I'm starting and when I'm ending a merge or compare. The waiting time for ending a web debug session is also about 30 seconds.

我没有特殊配置.TFS 服务器在我们的局域网中，我通过以太网连接.我没有在 TFS 设置中配置代理.

I have no special configuration. The TFS server is in our LAN and I'm connected via ethernet. I do not have a proxy configured in TFS settings.

我已经尝试了以下方法:

I already tried the following:

已删除的 suo 文件向 Visual Studio 2013 应用配置添加了禁用代理的设置.在本地存储符号重新添加映射重新添加工作区

我对 TFS 之外的项目没有这个问题.我的同事没有这个问题.

I'm not have this problems with projects that are outside TFS. My colleagues are not having this problem.

推荐答案

有许多您还没有尝试过的选项:

There are a number of options available to you which you haven't tried yet:

当你有一个大工作区(意味着你的工作区中有很多文件)或者当你的工作区包含很多二进制文件(例如 NuGet 包)时，当它被配置为本地工作区"时，它可能会显着减慢.本地工作区将原始文件(TFS 服务器知道的最新版本)保存在磁盘上的 gzip 文件中.每当大量文件发生更改时，都会将它们与最后一个已知副本进行比较，并根据它们被签入或签出.

When you have a large workspace (meaning lots of files in your workspace) or when your workspace contains a lot of binary files (NuGet Packages for example), it may slow down considerably when it's configured as a "Local Workspace". Local workspaces keep the original file (latest version as your TFS server knows it) in a gzipped file on disk. Whenever a lot of files change, they're compared against the last known copy and based on that they're either checked in or checked out.

另一方面，服务器工作区只是查看文件的只读"位.如果它有一个，TFS 将假定它没有改变.如果没有，TFS 会假定它已被签出.

A Server workspace on the other hand simply looks at the 'read-only' bit of the files. If it has one, TFS will assume it's unchanged. If it doesn't have one, TFS assumes it's checked out.

本地工作区有其优势，特别是如果您经常离线工作，但在上述情况下它们可能会导致严重的减速.

Local workspaces have their advantages, especially if you work offline a lot, but they can cause serious slowdown in the cases described above.

尝试将您的工作区配置为服务器工作区，看看是否能解决问题.

Try configuring your workspace as a Server workspace to see if that removes the issue.

默认情况下，Visual Studio 会在引入此功能后创建本地工作区.

Visual Studio, by default, creates a Local workspace ever since this feature was introduced.

如果您想使用本地工作区，您可能需要更新您的解决方案以确保未检入 NuGet 包、隐藏工作区中的大型二进制文件并且您只获取真正需要的文件(例如创建不同分支的新工作区).

If you want to use a Local workspace, you may need to update your solution to ensure that NuGet packages are not checked in, large binary files in your workspace are cloaked and that you only grab the files you really need (e.g. create a new workspace for different branches).

要隐藏文件，请编辑您的工作区映射并添加您不想检索的文件夹并将操作从活动"设置为隐藏"，或者您可以直接从源代码管理资源管理器的上下文菜单隐藏，您可以在 Advanced 下找到它，然后在 Cloak 下找到它.

To cloak a file, either edit your workspace mapping and add a folder you do not want to retrieve and set the action from "active" to "cloak", or you can cloak directly from the context menu of the Source Control Explorer, you can find it under Advanced then Cloak.

与其检查二进制引用，不如尝试查找相应的 NuGet 包，或自己创建它们.在版本控制系统方面，大型二进制文件总是有害的，因为您永远无法合并它们，而且它们基本上只是坐在那里.

Instead of checking in your binary references, try to find corresponding NuGet packages, or create them yourself. Large binary files are always a pest when it comes to Version Control Systems, as you can never merge them and they basically just sit there.

团队资源管理器客户端将缓存保存在以下位置:

The Team Explorer client keeps a cache in the following location:

C:\Users{用户名}\AppData\Local\Microsoft\Team Foundation{版本}\Cache

C:\Users{user name}\AppData\Local\Microsoft\Team Foundation{version}\Cache

由于某种原因可能已损坏.清除所有子文件夹和 VersionControl.config 可能是让它再次工作的最后手段.

Which may have become corrupted for some reason. Clearing all sub-folders and the VersionControl.config can be a last resort to get it working again.

有时 Visual Studio 本身会被所有修补程序、服务包和其他安装的东西弄糊涂.甚至不提及可能影响其行为的所有扩展.

Sometimes Visual Studio itself can be a little confused by all the hotfixes, service packs and other things that get installed. To not even mention all the extensions that may influence it's behavior.

某些扩展会严重减慢与源代码管理的交互.例如，前面提到的源代码管理资源管理器扩展具有更改磁盘上文件日期的选项，这可能导致获取"操作在最后停止数秒.

Some extensions can seriously slow down interactions with source control. The before mentioned Source Control Explorer Extensions, for example have an option to change the date of the files on disk, which can cause "Get" operations to stall at the very end for a number of seconds.

关闭此类扩展以查看没有它们的行为是否仍然存在，这始终是您应该做的事情.修复 Visual Studio 并重新应用最新的更新包也可以解决此类问题.

Turning off such extensions to see if the behavior still exists without them is always something you should do. Repairing Visual Studio and re-applying the latest update pack is also something that may resolve issues like these.

可疑扩展包括那些:

扩展调试器扩展团队资源管理器扩展源代码管理资源管理器

当 Windows 代理自动检测打开时，我看到了一些奇怪的行为，不是在所有网络上，也不是在所有代理服务器上.代理检测可能会导致长时间等待，因为它试图找出要连接的代理.

I've seen some strage behavior, not on all networks, not with all proxy servers, when Windows Proxy Auto Detection is turned on. Proxy detection can cause long waits as it's trying to figure out what proxy to connect to.

尝试禁用代理脚本和自动检测，如果您依赖代理，请尝试直接在经典代理配置屏幕中进行设置:

Try disabling the proxy script and auto-detection, if you're dependent on a proxy, try setting it directly in the classic proxy configuration screen:

启用 如上所述的客户端跟踪这里.在 devenv.exe.config 中包含以下代码段.它会将 TFS 周围发生的所有事情转储到日志文件中.查明正在发生的事情可能会很痛苦，但它会给您提供大量信息:

Enable client side tracing as described here. In the devenv.exe.config include the following snippet. It will dump everything that happens around TFS to a log file. It can be a pain to pinpoint what's happening, but it will give you loads of information:

<system.diagnostics>
  <switches>
    <add name="TeamFoundationSoapProxy" value="4" />
    <add name="VersionControl" value="4" />
  </switches>
  <trace autoflush="true" indentsize="3">
    <listeners>
      <add name="myListener" type="Microsoft.TeamFoundation.TeamFoundationTextWriterTraceListener,Microsoft.TeamFoundation.Common, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" initializeData="c:\tf.log" />
      <add name="perfListener" type="Microsoft.TeamFoundation.Client.PerfTraceListener,Microsoft.TeamFoundation.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
    </listeners>
  </trace>
</system.diagnostics>

并且您可以在启用活动跟踪记录的情况下运行 Visual Studio.如果有一个插件行为不当，它通常会导致 ActivityLog.xml 中的信息.要启用这种类型的跟踪，请使用命令行中的 /log 选项启动 Visual Studio.日志将被丢弃在这里:

And you can run Visual Studio with Activity Trace Logging enabled. If there's a plugin misbehaving it often results in information in the ActivityLog.xml. To enable this type of traces, start visual studio with the /log option from the commandline. The log will be dropped here:

%AppData%\Microsoft\VisualStudio\12.0\ActivityLog.XML

%AppData%\Microsoft\VisualStudio\12.0\ActivityLog.XML

在最坏的情况下，您可以将一个 Visual Studio 或分析器(或 Intellitrace 命令行工具)附加到 Visual Studio，并收集 Visual Studio 内发生的所有事情的日志.

In the worst case you can attach one Visual studio or a profiler (or the Intellitrace commandline tool) to Visual Studio and collect a log of everythign that happens inside Visual Studio.

您可以尝试使用 Process Explorer 监控您的系统以查看如果 IO 或网络访问使您变慢.

And you could try monitoring your system with Process Explorer to see if IO or network access are slowing you down.

这篇关于Visual Studio 2013 + TFS = 慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！