Retrieving TFS WorkItemStore horribly slow in debug build

I'm using the following code to retrieve a WorkItemStore in TFS:

TfsTeamProjectCollection _tfs = new TfsTeamProjectCollection(new Uri("<server>"));
_tfs.Authenticate();

Wo开发者_C百科rkItemStore _store = (WorkItemStore)_tfs.GetService(typeof(WorkItemStore));

The call to GetService takes at least a full minute to complete in a Debug build, but runs in a second or two in a Release build. I also tried other methods of creating a WorkItemStore (IE: new WorkItemStore(_tfs), etc.) with the same results. There is no difference in target platform, and there are no command-line arguments. Disabling the "Visual Studio hosting process" makes no difference.

Additionally, this code is part of a project recently added to TFS, and I didn't have this problem when I was working purely local. I tried creating a copy of the project and removing it from source control, and that also had no effect.

I'm about out of ideas...any suggestions on where to look next would be greatly appreciated.

You could enable the TFS trace flags and take a look at the log to see where the time is being spent. This blog post describes the process for enabling it for DevEnv.exe. If you are doing it as part of your build, you will probably need to add the trace flags to the build service .exe.config file.

TFS Client Tracing

Instantiating the WorkItemStore service is a very heavy-weight operation. TFS has a set of Metadata - this includes all the work item definitions, global list values, values for the Assigned To dropdown, etc. When you connect to the server for the first time, this has to be calculated by the server, sent to the client, processed on the client and then written to disk (cached).

When everything is operating normally, the metadata is cached to disk and only incremental updates are pulled down to the client on each connect. However, if the metadata couldn't be cached, then it will be a full update every time. The tracing should help you find out where it is being cached.

You can also change the cache location by setting a config setting:

<add key="WorkItemTrackingCacheRoot" value="C:\inetpub\wwwroot\FolderForCache" />

I can't think of a reason why it would be operating differently in a debug vs. release build, but hopefully the trace can help.

Resolved, but not by anything I did. One day it just started working normally again.