David Grey's Blog : Team Foundation Server

Windows Update Ate My Team Foundation Server

David — Thu, 12 Jul 2007 11:12:00 GMT

I came into work this morning to find that our Team Foundation Server was not operating correctly. Team Explorer clients could not connect to the server at all though everything on the server seemed to be properly configured and working. A quick check...(read more)

Connection problems after installing Team Foundation Server Service Pack 1

David — Sat, 16 Dec 2006 09:36:17 GMT

As you may have read (http://blogs.msdn.com/robcaron/archive/2006/12/14/1292136.aspx) Service Pack 1 for Team Foundation Server (and Visual Studio) has finally released. I've said it before and I'll say it again - Team Foundation Server really rocks!! It is the heart of our small software development business and if it stopped working for some reason we would be sunk. So you can guess how delighted I was after I had installed TFS SP1 to find that the Team Foundation Server was no longer working or accessible from any Team Explorer clients, even those running on the TFS server box itself. Every attempt to access the TFS server via Team Explorer or through a browser directly to the Web services resulted in a raft of HTTP 403 or 503 errors. Examining the event logs on the server showed a wide range of TFS errors including things such as not being able to load the UI culture information and the helpful TF53010: An unexpected condition has occurred in a Team Foundation component. Most interestingly the logs showed SQL Server login failures for the Team Foundation Server service account. After a couple of very frustrating hours of browsing events logs, IIS logs, etc I finally resolved the problem and thought I'd document it here for the benefit of anyone else who might experience similar issues.

Before you install TFS SP1 it informs you that you need to download and install another update first which puts the TFS server in a quiescent state so that there is no activity going on on the server whilst the update is performed, otherwise the TFS database may become corrupted. Once this in place then you can do the update, which works correctly. The problems seem to stem first update puts the server in a quiescent state by applying an IP address restriction to the entire web server used as the application tier front-end so that it can only accept requests from the localhost address (if you have other web sites hosted on this server, like our main company website for instance, this really isn't funny, though I appreciate that was probably the easiest way for the VS team to achieve the behaviour they require for update.) It also modifies some of the TFS databases and places them into single-user mode. My guess is that at the end of the SP1 update these changes are supposed to be undone leaving the TFS server in its original state.

On our server, the IP address restriction was not removed from IIS and four of the TFS databases (TfsActivityLogging, TfsBuild, TfsIntegration and TfsVersionControl) were left in single-user mode. Manually temoving the IP address restriction using inetmgr and resetting the four databases back to multi-user mode using SQL Server Management Studio fixed the problem and all is now working as it should. Having finally brought TFS back to life, I have to say that it was definitely worthwhile installing SP1 as there are some noticeable performance improvements, and I haven't even had a chance to really paly with it yet.

Test results not published to build output during a TeamBuild

David — Tue, 20 Jun 2006 20:41:32 GMT

I stumbled across an interesting problem today whilst trying to enable unit testing as part of a TeamBuild on our Team Foundation Server.

One of our projects has an extensive test harness created using the unit testing features of Visual Studio 2005. This test harness exercises the business objects in the application, which in turn call in to the underlying database. The test harness tests the behaviours of the business objects and verifies that the correct changes have been made in the underlying database by executing direct queries against it. The tests run from a known good state of the database, which is achieved by dropping the relevant database, recreating it and populating it with known data before each test run.

Our test harness has been working perfectly on developer workstations for some time but we recently decided to make it part of the automated nightly build of the application that occurs on our Team Foundation Build Server. So today I enabled testing in the Team Build configuration file and set it to use the specific test lists we have configured for this set of tests. When I manually ran the Team Build it showed that the tests had failed and that there were no test results but the build log file showed that all test had passed. Logging on to the build server showed that there were the .TRX test result trace files present in the build directory but these were not being copied to the build drop directory, hence Team Explorer thought that no test results had been returned.

After quite a bit of poking around I finally figured out what was going on. The database files for the test database created at the start of each test run were being created by the test harness in the current directory; during Team Build testing the current directory resolves to the Test Results directory below the build directory. At the end of testing, Team Foundation Build attempts to copy the test results from this directory to the build drop directory and appears to do so by trying to copy all files from the Test Results directory. If, for some reason, it cannot copy a file the entire copy process fails. In our case, the database and database log files were stored in this directory and Team Foundation Build was trying to copy these to the build drop directory along with the test results, but could not do so because the files were locked by Sql Server. As these were the first files it tried copying, none of the actual test results got copied to the build drop location and a test failure was reported because the test result files could not be copied, not because any of the tests had failed.

I resolved the problem by modifying the test harness so that it creates the database and log files in a temporary directory on the server, not the current directory. Team Foundation Build can then copy all test results files to drop directory and Team Explorer now acknowledges the presence of test results. Moral of this story.... don't rely on using the current directory when running automated tests on the server. They may work fine on a developer workstation but that doesn't mean it will work as desired on the build server.

------
David

How to install and configure Visual Studio Team Foundation Server

David — Sat, 02 Jul 2005 13:03:00 GMT

If you've tried installing and configuring Visual Studio Team Foundation server yet, you'll know that it's a fantastic example of a software product that is easy for the end user to install and configure - not!!! There also seems to be a singular lack of any real documentation at this point though there are plenty of posts on the Web regarding installation failures, etc. I've spent two days this week trying to get Team Foundation Beta 2 up and running on one of our servers so we can evaluate it. If you're thinking of setting it up then I'd offer the following tips:

Sounds obvious, but... read the Installation Guide that comes with Team Foundation server and follow it to the letter. Slight deviations from it seem to result in failed installs and the dreaded 32000 error
Use the bits that come with beta 2 when installing Team Foundation server. I can tell you from 6 hours of bitter experience (and from this post) that it doesn't seem to want to install on the SQL Server 2005 June CTP (T-SQL scripts failures probably due to changes in T-SQL changes in the June CTP), but works fine on the April CTP that comes with the beta
When you finished installing, don't forget to add account(s) to the Namespace administrators group as described in the installation guide
Set up the authentication properly for creating new projects. This bit is really unclear and caused me much head scratching when trying to create some new projects. If you follow the steps in this post it does work
If you're trying to get Team Foundation to perform builds on the server for you then don't forget to install the Team Build component as described in here and here. For some reason best known to the guys at MS, the Team Build doesn't get automatically installed by the main install and you have to install it manually once you've got Team Foundation server up and running.

Having finally got Team Foundation working properly I created a project for an ASP .NET application we're working on at the minute and tried to build it. Guess what? It failed because the ASP .NET compiler couldn't find the source files in that right place. This is due to the solution file containing absolute paths to files the development machine and they need to be modified as described here. Having modified the solution file, the ASP .NET application now builds perfectly on the Team Foundation server and seems to (mostly) still build correctly on the development box. I haven't tried checking the project out to a different location or on another box to see if it still builds correctly there - that's my next job!

If you're looking for information on setting up and using Team Foundation server then the MSDN Team System forum is a great place to start, though Google will probably become your best friend too!