I ran into a problem today as we were trying to get a build out with our new implementation of Team Foundation Server.
The problem was that there was a reference path set in each project of the solution (some 30+ projects) that pointed to some directory that didn't actually exist on my machine, but did on most other machines. Since the paths for all the libraries specified as project references are merely "hints" (having been converted to relative paths) that Visual Studio may or may not pay attention to during the build process, every time someone else (who had the reference path directory) tried to build the solution, they used the wrong version of a particular library.
No big deal ... just clear out the reference paths for each project. Unfortunately, the reference path information is not actually part of the project. It is part of the user-specific information about the project, stored in (for a vb project) the *.vbproj.user file. As such, it's not technically part of the project, so changes to it are not pushed up into TFS. Which shouldn't be an issue, since these are user specific. So where was this information coming from?
The actual problem was that someone's *.vbproj.user files had been included as part of the projects when they were added to TFS. Whoever set things up probably had to do an "add folder" from the source control interface, because the "add to source control" context menu seems to be fickle about showing up in VS 2005.
Be aware of this scenario when setting up your own projects in TFS based on existing code.