Visual Studio 2013, TFS is very slow

问题:

When I originally installed VS Ultimate 2013 everything was fine but for the last month or so it's been a dog. The source control explore in my Visual Studio 2013 install is very slow. Just clicking on a node and the act of displaying the node contents takes 20+ seconds.

Everyone else on the team is ok so it's not the TFS server it's just my install. I assumed it was some addin I'd installed into VS so disabled them but no luck.

Any ideas?

回答1:

Having tried all suggestions, unloaded all add ons, tried to reinstall VS, removed all extra workspaces etc. the answer to my problem was to unmap my workspace and then remap it. Problem solved. Not got a clue what the underlying fault was.

回答2:

In my case, the only way to get rid of the lag was to change my workspace location from "local" to server. You can do this under the advanced options for your workspace.

回答3:

The 'full blast' solution that worked for me was;

• remove workspace
• delete all source code
• rebuild the workspace
• rebuild solution

Only takes a few minutes more than just rebuilding the workspace (see @DaveF's answer) but gave me a bit more confidence that everything hangs together.

回答4:

Cleaning local folders helped: See 'Team Explorer - Pending Changes', under 'Excluded Changes' it said: 'Detected: 50000 add(s)'. Click it to see path to folders.

回答5:

Had this happen to me a few times now, so there are some things I'd like to add to the accepted answer.

I work in a place where we have a lot of VS solutions with a lot of files in them. Microsoft's guidelines suggest that you shouldn't be using a local workspace if its going to have more than 100,000 items in it. So you could prevent this problem entirely by:

1. Not using local workspaces
2. Making sure never to map enough folders into a single workspace that it gets over 100,000 files associated with it.
3. Periodically declaring "TFS bankruptcy" and unmapping everything.

For me, the drawback of having to use strict locking and not having offline access makes #1 unacceptable. I'm going to try harder to do #2, but honestly #3 is what I've been living by.

Its kind of like early Windows, where every year or so you had to just reinstall the OS to remove all the accumulated cruft.

回答6:

This make me crazy too for over six months until I found this instruction. Now, my VSO is fling. Note: this information I copy from somebody. Would like to give them credit but I cannot remember how did I find this.

You can fix this problem of TFS by editing registry. Navigate to key HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Proxy and then change value of URL to any dummy website like 'www.abcdummy.com' Restart VS after editing registry key value.

回答7:

I had the same problem, it kept me busy for a week or so, but after investigating my complete setup i found the following:

Within my ASP.NET application, i had an image directory and an image cache directory, with lots of images in them. (+200.000). Both were not included in my VS project, but still Visual Studio / TFS tripped over this.

First i found, that when checking in some files (which took over 10 minutes when the problem existed), in 'Team Explorer - Pending Changes', under 'Excluded Changes' it said: 'Detected: 50000 add(s)'. Trying to get rid of this the 'normal way', by opening that 'Promote Candidate Changes' window and setting these files to be ignored, still didn't do much. But after moving those image directories to some other location, outside my project, all problems disappeared. Of course i had to add those moved directories as virtual directories to still see my images.

回答8:

I cleaned my workspace of unnecessary projects and it ran better. I think vh_click is on to something with the 50,000 ads thing. TFS keeps track of all your edits and over time with tons of projects, undos, and craziness you could amasse a large set of which TFS has to chug. Get out the Clorox, the Comet or whatever else you clean with and dump some junk or move it to some archive folder or backup drive.

回答9:

Cleaning up the Workspace was the solution for me, when opening visual studio 2015 the Source Control Window will remain in a Loading phase, I had 2 workspaces name and name_1 and I removed both. No need to delete the entire folder, though , keep in mind that if you do delete the workspace and have the files, you will need to force the get latest to be on the safe side

回答10:

Getting Latest was soooooo slow. I was using a Colleagues PC and had deleted his Workspace.

After an hour waiting to get latest I got an error and realised my User Account didn't have Full Control on the folder, giving Write Access made Get Latest run x1000 faster:

回答11:

Just to throw another solution in the mix! I had the same problem which seemed to be caused by several layers of working folders configured in my workspace (some overlapping ones too).

The issue was resolved by going to Manage Workspaces, then Edit and then removing the additional folder bindings.