Chris Cooper comes to us today with the story of a TF server, a client, and the Fiddler who saved the day….
The other day I had a customer that had the dreaded Red-X on his documents node for one of his Team Projects in Team Explorer. The rest of the Team Projects did not have the Red-X and were fully accessible through Team Explorer. So the first thing I checked were the SharePoint permissions granted to the users for that particular Team Project (TE Documents node = SharePoint). That all checked out. I then had him browse the site in Internet Explorer – worked just fine too.
So the next place I went were the IIS logs. Once again, everything appeared normal – I could see the handshake and the 200 response. Well I guessed then it was time to turn on some logging to try to figure out just what the heck was going on.
The first thing I thought of was a system.net trace. You can enable this in the Devenv.exe.config file (usually in C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE) by adding the following to the file (make sure you close Visual Studio first):
<system.diagnostics> <trace autoflush="true" /> <sources> <source name="System.Net" maxdatasize="1024"> <listeners> <add name="MyTraceFile"/> </listeners> </source> <source name="System.Net.Sockets" maxdatasize="1024"> <listeners> <add name="MyTraceFile"/> </listeners> </source> </sources>
<sharedListeners> <add name="MyTraceFile" type="System.Diagnostics.TextWriterTraceListener" initializeData="c:\System.Net.trace.log" /> </sharedListeners> <switches> <add name="System.Net" value="Verbose" /> <add name="System.Net.Sockets" value="Verbose" /> </switches> </system.diagnostics>
We opened Visual Studio and Team Explorer, which tried to connect to and refresh the Documents node, and then I viewed the trace results. What was interesting was that I could see the successful call to list libraries and list items but nothing was returned from the server.
So on to Fiddler. You can get fiddler from the following site:
This finally did it for me – this is what I saw in the logs:
<List DocTemplateURI=”/sites/My Project/test1/template.doc” DefaultViewURI=””
One of the document libraries (“test1”) in the problem project had a missing “DefaultViewUrl” setting. TFS parses for all the DefaultViewUrl’s in all the document libraries in order to successfully connect to the Documents in the project so one missing setting can cause this issue. The simplest way to resolve this issue is to delete the “test” document library using SharePoint Site Settings for the Project site. This is only a viable solution if the documents that are in the “test” library are not needed. If they do need to be saved they can be copied out then added to a new document library created after the “test” library is deleted.
I had one other experience recently using Fiddler that I’d also like to tell you about. We had another customer, similar issue, could browse the portal but had a Red X on the documents node. I went through the same steps as before, but still did not have an answer.
So back to Fiddler. Looking at the log I saw that there were about 75 document libraries on this site. The Documents node in Team Explorer 2005/2008 only supports 64 libraries, then it fails. What happens is that 2005/2008 clients try to populate the contents of all the document libraries on initial connection to the project. The client issues 75 requests to the server, one for each document library, each on a separate threadpool thread, then it attempts to wait for them all to complete. One problem with this is that you can only wait on 64 handles at a time, so it fails.
The only workaround is to decrease the total number of document libraries on the site, or wait for the 2010 TFS client.
So the morale of the Red-X on Documents node in Team Explorer story… this can fail if:
1. The user doesn’t have at least read access to all of the document libraries.
2. There are more than 64 document libraries (TFS 2005\08).
3. One or more of the document libraries has an incorrect or missing ‘DefaultViewUrl’, which can result in the TE not being able to retrieve the path name for a document library.
4. Any of the subsequent call to get the contents of a document library fails.
5. Sun spots. ;-) [ed]
The "DefaultViewUrl" failure mode was unknown to me. Caused much head-scratching on a certain deployment...until I saw this post in my RSS reader last week. Worked like a charm. Thanks a zillion, Chris & Trev!