Microsoft's solution to integrated software project management, the Team Foundation Server product, offers a lot of services. Beyond Source Control they have a work item tracking, build services and reporting in stock (I suspect there is even more functionality under the hood). You might be tempted to think that such an "all-in-one" solution can become complex to manage pretty soon. Let me tell you, it does! A couple of months ago I set up a Team Foundation Server (beta 2) for a project some friends of mine do for Microsoft (you will hear of it, I promise).
The server was initially installed as a virtual machine on our pretty decent server connected to the DSL line at home. The installation alone took me a week to complete since there was a bug in some XML file that made Visual Studio 2005 misinterpret the file's contents. (I don't remember exactly the source of the problem.) It was quite a hassle to get my first TFS project created.
The project hosted on that server went well, but it became pretty soon obvious that the team needed more resources in respect to bandwidth and virtual machines for testing the application they build. That's something we could not handle with our 640 kbit/s upload bandwidth and 1,5 GBs of RAM in the server. We moved the TFS virtual machine to another physical machine (more RAM) and hooked it up to the University network (lots of free bandwidth).
After moving the server we found that new projects could not be created due to one misconfigured Team System service URL, i. e. that service could be accessed on the home network (think http://tfs/) but not over the Internet. Specifically it was the URL to the SharePoint Central Administration Web Site, but that doesn't actually matter. I checked TFS' Registration Service to see if the corrected URL has been applied. The Registration Service URL looks like this:
WssAdminService has a publicy known URL. Good to go! I tried creating a new project, but received that same error as before.
The error message above is a bit misleading because the Team Foundation Client did not try to connect to tfs.therightstuff.de, but rather to the (old) tfs server, as Fiddler revealed.
Looking through the other HTTP requests originating from Visual Studio's Team Foundation Client I found that the Registration Service has never been queried to get the updated service URLs. On Buck Hodges' blog I found a hint:
When a client app, such as tf.exe, VS, or your own custom application, needs to use version control, the TF client code must request the service definition from registration service on the server. To avoid constantly requesting service registration information that rarely changes, the client-side registration code maintains a cache and only makes the server call when the cache is out of date.
Whatever it means that the client re-requests that piece of information when it's out of date. On my machine the Team Foundation cache mentioned above is located at the folder
C:\Users\<User name>\AppData\Local\Microsoft\Team Foundation\2.0\Cache\
I wiped the cache folder and, just to make sure, I also deleted the TFS server registration in Visual Studio.
After re-adding the TFS server in Visual Studio I can now create new Team Foundation projects. Wow!