Troubleshooting Team Explorer ->Documents node problems

(Chinese version of this post) 

One can read & operate the documents from the Team Explorer->TFS Server Name->Team Project Name->documents node. In this post I briefly talk about how the document hierarchy is displayed in the tree view, some observed failing senarioes, and ideas of troubleshooting the documents node.

When one logon to Team Explorer, or click “refesh” on a team project node:

1. Team Explorer calls a WSS web service http://<WSSServer:port>/sites/<project name>/_vti_bin/Lists.asmx, web method GetListItems . The parameters are defined to retrieve all folders/files under the team project document library’s root folder recursively. The request is made under the current user’s credential rather than the TFS serivice account.

2. WSS web service returns an XML response which is basically a batch of requested records, one record for each file/folder. Each record contains several WSS properties describing that item.

3. Team Explorer re-establishes the hierarchy according to the “ows_FileRef “ property of each record. For a “\” ended item , a folder node will be created in the tree; for a none “\” ended item, a file node will be added to the coresponding folders. Say if TE find a record of “\folderA\folderB\fileC.doc”, it will put it under folderA’s sub folder folderB as fileC.doc. So it is quite streight forward.

Now let’s see some “unexpected” senarios:

l A red cross on the “Documents” node. Since the request to the WSS web service is sent with the current user’s credential, if this user does not have the required permission to read this document library, no data will be retrieved. This is a common question from new TFS users. Team project group membership & permission settings are for workitem tracking and source control only. For team members to access the project portal & document library, the project manager must set up permissions in the WSS site accordingly. Similarly, additional permission settings in the reporting service web site is required before team members can access the project reports.

       Another possible reason is the target WSS service is not available (for that client machine) at that moment. Both senarios are easy to verify using a web browser.

l The document hierarchy is mess-ed up. Once a customer reported that the document tree was wrong. A folder was missing from the tree, while the documents that should be under that folder were placed directly under the root path of the “Documents“ node. Examining the WSS response to “GetListItems” in the network monitor log, we found out that all item records were there except for the one of the missing folder. So when Team Explorer set up the tree, it did not create a node for that folder; and, not knowing where to put the documents, it put them directly under the root. It turned out that the WSS database record of that folder was missing. Making it up in the WSS database, and the problem was solved.

By the way, when the record was missing in the database, the WSS web site was smart enough to handle the situation. The folder and the documents were shown nicely under the expected path in the WSS web site, which made the problem rather like a Team Exploer one.

l Some files/folders are missing from the tree. Check the document library—does it contain over 10,000 items? When Team Explorer calls the “GetListItems’ web method, the parameter “RowLimit” is set to 10,000. So this is the maximum number of records Team Explorer can retrieve, covering both files and folders. This non-configurable limitation applies to both Team Explorer 2005 & 2008, and the future version may increase the number. If your document library exceeds this limitation, the workaround is to view the documents in the WSS web site.

Now, troubleshoot ideas when you get trouble with the Team Explorer->Documents node:

1. On the same computer, with the same user account, use a web browser to view the project portal . See if the WSS web site can display the interested contents properly. If this site gets the same problem, it’s a WSS side issue; otherwise go to step 2;

2. Use a network sniffer (MS network monitor,wireshark, fiddler, etc.) to collect the network trace between Team Explorer and the WSS server. Check the request & response arround URL /sites/<project name>/_vti_bin/Lists.asmx, see if the request is to the correct server , passing the correct parameters, and if WSS responds with the expected record set.

3. If the response from WSS is thought to be correct in step 2, it might be a Team Explorer issue. Raise the question to the MSDN forum, or contact Microsoft technical support.

Have fun.