Team System

Team System Bug Entry Webform for ASP.NET

A common request for ASP.NET projects that are using Team System is to have a "new bug" webform. This way, customers or users have a way to get their bug submissions directly into Team System.

I whipped up a quick little "hello world" demo of an ASP.NET webform that connects to Team System and enters a bug on behalf of the user. It's a single page plus a configuration section, with some basic error handling logic in case something goes wrong.

Download the Visual Studio 2005 solution (7kb)

It's intentionally simple as is, but you could easily extend it to add more complex work items with attachments, and so forth.

The web.config looks like this:

<configSections>
  <sectionGroup name="TFS">
    <section name="Server" type="TFSConfigurationSection, TFSWebDemo"/>
  </sectionGroup>
</configSections>

<TFS>
  <Server server="http://tfsserver:8080" userName="username" password="password" domain="domain" project="projectname" />
</TFS>

Be sure to edit this to select the right server, user, and project. Note that you may need to grant permission to the 'C:\Documents and Settings\Default User\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache' folder for the user specified in web.config. Or at least, I did on our web server.

Is Team Foundation Server 64-bit capable?

Recently, I was asked whether Team Foundation Server works in a 64-bit environment.

The answer to this question depends on whether you have a dual-server TFS install, or a single-server TFS insall.

If you have a single-server TFS install, you must use a 32-bit operating system.

If you have a dual-server TFS install, some parts of TFS can be installed on a 64-bit operating system:

• The data tier fully supports 64-bit. You can use a 64-bit edition of SQL Server to host the TFS databases.
• The build server and Visual Studio 2005 can run fine under the WOW64 emulation layer on any 64-bit edition of Windows.
• The application tier must be installed on a 32-bit edition of Windows.
• The Team Proxy must be installed on a 32-bit edition of Windows.

I imagine TFS will be more fully 64-bit in the next release. But for now, at least you can take full advantage of a 64-bit operating system for the database portion of TFS.

Troubleshooting "Team Foundation Server cound not resolve the user or group"

Here's what to do when you're adding an Active Directory user to a Team Project and you run into this error:

Team Foundation server could not resolve the user or group (name). The user or group might be a member of a different domain, or the server might not have access to that domain. Verify the domain membership of the server and any domain trusts.

As documented in this forum thread, this error usually occurs when the client attempting to add a user to a Team Project doesn't have the same domain permissions as the Team Foundation Server.

The first thing to try is adding the user via the Team Foundation Server. Log in to the server and either use the tfssubscribe.exe command line tool, or if Visual Studio 2005 is installed on the server, add them that way. But make sore you do this on the server.

If adding the user works on the server, but doesn't work on the client, then you know it's due to the difference between client domain permissions and the TFS domain permissions.

UPDATE: Don't forget to check the credentials of the TFS service accounts. If the TFS service account password has expired, or if the TFS service account is otherwise invalid, you can see this error message as well.

Incorporating a ClickOnce Application into your Team Build

I found out last week that the Team Build server doesn't perform the essential Publish step that makes a ClickOnce app, well, a ClickOnce app!

But this is easy enough to fix.

Let's start with a simple Hello World ClickOnce app that has one shared DLL dependency. If we do a Team Build for this app, we get the following files in the drop folder:

OneClickApp.application
OneClickApp.exe
OneClickApp.exe.manifest
SharedLibrary.dll

Notice anything missing? To be fair, even in the Visual Studio 2005 IDE, Publish is a seperate step from Build that you must manually invoke via a different menu.

Even if you're building and publishing the project remotely on the build server, you must Publish locally at least once, so all the Publish preferences are stored in the project files.

In order to Publish a project on the Team Build server, we have to make a small edit to the tfsbuild.proj file. Under the SolutionToBuild XML element, add a SolutionToPublish element:

<ItemGroup>
  <SolutionToBuild Include="$(SolutionRoot)\OneClickApp.sln" />
  <SolutionToPublish Include="$(SolutionRoot)\OneClickApp.sln" />
</ItemGroup>

Check this change in, then try rebuilding. Now the drop folder contains the Publish results, too:

OneClickApp.application
OneClickApp.exe
OneClickApp.exe.manifest
SharedLibrary.dll
OneClickApp_1_0_0_0\OneClickApp.exe.deploy
OneClickApp_1_0_0_0\OneClickApp.exe.manifest
OneClickApp_1_0_0_0\SharedLibrary.dll.deploy
setup.exe

See all the new files at the bottom? With that small edit, this build is now functionally equivalent to a local Build plus Publish.

Copying Web Files After a Team Build

After building a web project in a Team Build, you probably want to deploy that website to a target server. And what better place to do this than in the build scripts themselves?

This is pretty easy to do; we'll just customize the AfterBuild event to XCOPY the contents of the \_PublishedWebsites folder somewhere. Note that you must grant permission for the Team Build account to the target UNC path first-- otherwise the copy will immediately fail!

There are two slightly different ways to do this, depening on what kind of web project you chose.

If you are using Web Application Projects, you'll need to edit the project file. The easiest way to do this is to right-click the project and select "Unload". After doing that, you can right click the unloaded project and edit the project file directly within Visual Studio:

Edit the project file to include the following command. The variable $(WebProjectOutputDir) conveniently includes the exact path we want:

<Target Name="AfterBuild">
<Exec Command="xcopy /y /e &quot;$(WebProjectOutputDir)&quot; &quot\\remote\share&quot;"/>
<Target>

Save this, check it in, then perform a Team Build. You should see the XCOPY command work in the build report, like so:

Target AfterBuild:
xcopy /y /e "c:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\
WebApplication1" "\\remote\share"
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\Default.aspx
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\Web.config
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\bin\SharedLibrary1.dll
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\bin\SharedLibrary1.pdb
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\bin\WebApplication1.dll
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\bin\WebApplication1.pdb
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\bin\WebService1.dll
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\bin\WebService1.pdb
8 File(s) copied

If you are using Web Site Projects, you must have one Web Deployment project for each Web Site. Until you do, there's nothing to edit, and nothing to deploy. You'll be editing the Web Deployment Project directly: right click it and select "Open Project File" to begin.

It's almost the same as the previous XCOPY command, except the variable you want this time is $(WDTargetDir). Unfortunately this path includes a trailing slash, so we have to add a period afterwards to indicate that we want to copy the contents of the folder.

<Target Name="AfterBuild">
<Exec Command="xcopy /y /e &quot;$(WDTargetDir).&quot; &quot;\\remote\share&quot;"/>
</Target>

Save this, check it in, then perform a Team Build. You should see the XCOPY command work in the build report, like so:

Target AfterBuild:
xcopy /y /e "c:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\
WebSite1_deploy\." "\\remote\share"
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\Default.aspx
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\PrecompiledApp.config
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\web.config
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\bin\App_WebReferences.compiled
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\bin\SharedLibrary1.dll
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\bin\SharedLibrary1.pdb
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\bin\WebSite1_deploy.dll
7 File(s) copied

You could achieve the same effect by modifying a post-build event in the Team Build script, but I find it easier to modify the individual projects.

Building a Web Site Project with Team Build

If you're still using Web Site projects, I strongly urge you to switch to Web Application Projects. Web Application Projects are included in Visual Studio 2005 Service Pack 1. There are lots of good technical and practical reasons to make the switch, especially in Team System. But I digress.

If you're still using Web Site projects, you'll have to make some modifications before you can build these projects using Team Build.

In order to build a Web Site project at all, you must add a new project type to your solution-- the Web Deployment Project. It's a new project type that you'll need to download from Microsoft and install. But don't worry: it's a very small download, and a quick, painless install.

Once you have Web Deployment Projects installed, right click each web site and select "Add Web Deployment Project".

Once you have the deployment projects set up, make sure they're deselected in Configuration Manager for the Debug builds. There's no need to waste compile time on deployment until you're ready to create a release.

After you do a Team Build for this project, you should see a new _PublishedWebsites folder in the drops folder that contains the website and dependencies:

Now, this is the behavior you'll get by default with a Web Application project, but for each Web Site project, you must have one Web Deployment Project in place to get things working.

Speeding up Team Builds

If you're testing a complex new team build, you may find yourself going through a lot of build cycles. This can be painful, because most complex builds also take a while to complete.

To speed up the build process, you can skip some parts of it. You can do this in one of two places. First, in the TFSBuild.proj, you can insert these elements in the PropertyGroup:

<!-- insert in PropertyGroup -->
<SkipClean>true</SkipClean>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>
<ForceGet>false</ForceGet>
<SkipWorkItemCreation>true</SkipWorkItemCreation>
<SkipLabel>true</SkipLabel>
<SkipPostBuild>true</SkipPostBuild>

Alternately, you can edit the TFSBuild.rsp file to achieve the same results:

# This is a response file for MSBuild
# Add custom MSBuild command line options in this file
/p:SkipClean=true;SkipInitializeWorkspace=true;
ForceGet=false;SkipWorkItemCreation=true;
SkipLabel=true;SkipPostBuild=true 

(Note the above should all be on a single line; I broke it up for ease of display.) What are we skipping here? Well, we skip...

• .. deleting the source code folder
• .. doing a "force get" of the source code, so we use the code that's already present on disk
• .. labelling after completing the build
• .. compiling a list of work items that changed in the build
• .. creating a work item when the build fails

But despite all the skipping, the essential part of the build still completes. And that's usually what we're trying to troubleshoot.

(thanks to Dave McKinstry and Omar Villarreal for these tips!)

Making Team Builds More Verbose

Build engineering is one of the most challenging parts of Team System. It can be difficult to get a Team Build working exactly the way you want. When you're troubleshooting a build, the build log output file, BuildLog.txt, is your best friend.

The build log is fairly helpful as-is, but it's possible to make it even more verbose in those times when you're troubleshooting an obscure build problem.

Visual Studio, like Team Build, also uses MSBuild under the hood to compile solutions. In Visual Studio, you can set the build verbosity via a handy IDE setting. It's under Tools, Options, Projects and Solutions, Build and Run. The "MSBuild project build output verbosity" field offers four values: Quiet, Minimal (the default), Normal, Detailed, and Diagnostic.

You can also set verbosity via a Team Build script.

MSBuild.exe supports the verbosity command line parameter:

/verbosity:<level> Display this amount of information in the event log.
                   The available verbosity levels are: q[uiet], m[inimal],
                   n[ormal], d[etailed], and diag[nostic]. (Short form: /v)
                   Example:
                     /verbosity:quiet

All we need to do is edit the TFSBuild.rsp file in our TeamBuildTypes folder to pass this parameter on to MSBuild.exe:

# This is a response file for MSBuild
# Add custom MSBuild command line options in this file
/v:diag

Check TFSBuild.rsp in, and then do a build. The resulting BuildLog.txt will be much more.. er.. verbose!

Here are the results of running a build for each verbosity level:

diagnostic	825 KB
detailed	288 KB
normal	48 KB
minimal	12 KB
quiet	0 KB

The default verbosity level for Team Build is normal, so be careful when ratcheting it all the way up to diagnostic!

Team Foundation Server Event Subscription Tool

The Team Alerts dialog lets you subscribe to basic email alerts on a Team Project.

But the dialog is severely limited; the full richness of the email subscription mechanism in Team Foundation Server isn't available. To set up advanced subscriptions, you needed to use bissubscribe.exe. This is problematic, because the command-line syntax is complicated, and also because bissubscribe.exe is only available on the Team Foundation Server.

To address this deficiency Naren posted a GUI tool that lets you create Work Item Event Subscriptions in July 2006. I took that tool and modified it so that it supports all event subscriptions, along with a bunch of other enhancements The new Team Foundation Server Event Subscription Tool is up on CodePlex now.

Some examples of subscriptions you might want to create are:

Email me when any new work item is created:

PortfolioProject = 'TeamProject1' AND ChangeType = 'New'

Email me when any work item moves to the resolved state:

"CoreFields/StringFields/Field[ReferenceName='System.State']/NewValue\" = 'Resolved'

Email we when a specific (string) field changes in a work item:

PortfolioProject = 'TeamProject1' AND "ChangedFields/StringFields/Field[ReferenceName='field']/NewValue" <> null

Email me when someone checks source code into a specific folder:

'Artifacts/Artifact[starts-with(@ServerItem, \"$/TeamProject1/A\")]' <> null

Email me when someone overrides a checkin policy:

TeamProject = 'TeamProject1' AND PolicyOverrideComment <> ''

The queries are all based on XPath applied to the Event XML. As you can see, it's quite powerful-- far more powerful than the simplistic Team Alerts dialog would lead you to believe!

The path <path> is already mapped in workspace <workspace>

I recently ran into a problem with a local TFS server. Although I was logged in as my local account, TFS insisted that I was logged in as Administrator. Since the server thought I was a different user, it prevented me from opening my local workspace with this error:

The path is already mapped in workspace

The path conflict error reminds us of one important fact about workspaces: only one local path can be mapped, per user, per team foundation server. Two users can't share the same filesystem path. And two different team foundation servers can't share the same filesystem path, either.

The system caches your workspace mappings in this location, so if you're having workspace-related problems, it's worth clearing this cache file out:

C:\Documents and Settings\[user]\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache\VersionControl.config

As Buck Hodges points out, you can also clear the local cache file at the command-line:

tf workspaces /remove:*

But clearing the cache didn't help in my case. No matter how much I cleared, how many times I rebooted or logged off, I kept showing up as "Administrator", which means I was conflicting with myself! I could map to a new folder, but that's not what I want. How is this possible?

Well, it's possible if you physically log in to the Team Foundation Server using a different set of credentials. Those credentials are cached deep in the bowels of Windows, and retrieved automatically the next time you contact the server. That's our problem!

To clear the credential cache, try Start, Run, then type

control userpasswords2

And press enter. On the resulting dialog, click the advanced tab, and click Manage Passwords. Remove all cached credentials from this list.

Once I cleared the cached credentials, I was able to access the Team Foundation Server as myself again. Problem solved.

With this in mind, if you must log in to the Team Foundation Server, try to do so under your own credentials. It'll cause less problems later.

Modifying the default Team Build

One annoying thing about Team Builds created through the Team Build wizard is that they pull down all the source code in the entire Team Project by default. This is almost never what I want. But it's easy enough to fix.

First, check out the TFSBuild.proj and WorkspaceMapping.xml files from the TeamBuildTypes folder in source control.

Remember, the build user is just a user, exactly like you. And it has workspace mappings, just like you do. But in this case the workspace mapping is too broad. It's at the root of the Team Project. Let's fix that by editing WorkspaceMapping.xml. Change it from this..

<Mappings>
  <InternalMapping ServerItem="$/TeamProject1" LocalItem="C:\does-not-matter" 
    Type="Map" />
</Mappings>

To this..

<Mappings>
  <InternalMapping ServerItem="$/TeamProject1/DemoBuildWebApp"
    LocalItem="C:\does-not-matter"
    Type="Map" />
</Mappings>

All we're doing is adding the Solution folder to the Team Project path. This is the key fix-- until we do this, the build user will get latest on the entire source tree. That's no good.

Two additional notes about the build user workspace mapping file:

• If you do have a legitimate need to pull down a giant source tree, you can make it a little less painful by cloaking (aka hiding) some of the subfolders here.
• The path specified here is truly irrelevant. I changed it to C:\does-not-matter to make a point. The local path is always the server build folder, so whatever you put here is completely ignored.

Next, we need to update our compilation path to reflect the fact that it's no longer in a subfolder. Edit TFSBuild.proj and modify this section from..

<SolutionToBuild Include="$(SolutionRoot)\DemoBuildWebApp\DemoBuildWebApp.sln" />

To this..

<SolutionToBuild Include="$(SolutionRoot)\DemoBuildWebApp.sln" />

Now check in the changes, re-build, and you'll see in the build report and the build folder that only the specific source in the solution subfolder was retrieved. Big improvement!

Displaying Team System reports in the Team Portal

You can display Team System reports in the Team Portal using the default Page Viewer web part, which redirects to the URL

_layouts/tfsredirect.aspx?IsReport=1&ReportName=name

But there's a better way.

I recommend installing the SQL Server 2005 Reporting Services Web Parts. They're already on your server, but they're not set up. To set them up, run this command on your Team Foundation Server web tier:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN\
STSADM.EXE -o addwppack -filename 
"C:\Program Files\Microsoft SQL Server\90\Tools\
Reporting Services\SharePoint\RSWebParts.cab"

Once you do this, you'll have two new Web Parts specifically designed for reporting, so you no longer need to rely on the generic Page Viewer. Note that the new controls are in the "Virtual Server Gallery":

Here's the Report Explorer web part in action

And here's the Report Viewer web part in action:

The report gadgets work better. They offer much more control over the report output. For one thing, if you set any parameters to the report in design mode, those parameters are saved. You can also turn off the toolbar so the report comes up pre-configured to whatever parameters you last set.

Note that you will need to bits of information in the properties for each control:

• Report Manager URL: http://teamsystem/Reports
• Start Path (explorer): /teamproject
• Start Path (viewer): /teamproject/reportname

Remember, friends don't let friends use the generic Page Viewer web part to view Team System reports!

Customizing Work Items in Visual Studio

Customizing Work Item Types in Team System isn't quite as easy as it should be, but it's not difficult.

The Work Items are actually XML. To export them, you use the command line utilities witimport and witexport, which are located in the C:\Program Files\Microsoft Visual Studio 8\Common7\IDE path by default.

Here's how to export all 5 standard MSF Agile work item types (Bug, Task, Scenario, Quality of Service, and Risk):

witexport /f c:\task.xml /t %tfs% /p demo /n Task
witexport /f c:\bug.xml /t %tfs% /p demo /n Bug
witexport /f c:\scenario.xml /t %tfs% /p demo /n Scenario
witexport /f c:\risk.xml /t %tfs% /p demo /n Risk
witexport /f c:\qos.xml /t %tfs% /p demo /n "Quality of Service Requirement"

I created two little batch files which automate the process of exporting and importing all 5 standard Work Item Types from the MSF Agile template. You can download them here:

• export-all-work-item-types.bat
• validate-all-work-item-types.bat

Rename the files from .txt to .bat, and edit the path and TFS server name variables to match your environment.

Once you download the work item type XML files, you'll need to edit the resulting XML files to make whatever changes you need in the Work Items. There's some good guidance at MSDN on making common Work Item Type edits:

• Walkthrough: Make Basic Customizations to a Work Item Type
• Walkthrough: Make Advanced Customizations to a Work Item Type
• Walkthrough: Administer Fields in a Work Item Type

But editing raw XML still isn't my idea of a good time. You can make the experience slightly more pleasurable by adding IntelliSense to Visual Studio 2005 for Work Item Type XML. Rob Caron describes how. It's quite easy.

1. Download the process template schemas from the MSDN help topic Process Template Schemas Download.
2. extract the contents to: %ProgramFiles%\Microsoft Visual Studio 8\Xml\Schemas

After you copy the schemas to the right place, restart the IDE and you'll discover some shiny new IntelliSense when you begin editing the Work Item XML:

Once you're done making edits, validate your changes to make sure you didn't break anything.

witimport /f c:\task.xml /t %tfs% /p demo /v

Then, if you're happy with the validation results, remove the /v flag to import the work item.

witimport /f c:\task.xml /t %tfs% /p demo

And you're done! Wasn't that easy? OK, I wouldn't call it easy, but it's not too painful.

If you want something even easier, like a full-blown GUI tool to edit Work Item Types, you might want to check out the VSTS Customization Toolkit. It has some quirks, but it has worked fairly well the few times I've tried it. And it definitely beats editing raw XML.

Areas, Iterations, and Subscriptions

Team Projects are designed to be large-- they should host many solutions. Because Team Projects can be so large, that's why the Areas and Iterations dialog is so critical. Areas and Iterations allow you to logically slice up large Team Projects in space and time. Setting up a project structure via Areas and Iterations is one of the most important jobs a project manager has.

If you're wondering what this should look like, Eric Lee posted a great example of how Microsoft's internal VSTS development teams aggressively use Areas to logically divide a Team Project:

Areas and Iterations are important for another reason: they are one of the few places you can express hierarchy within work items. Outside of areas and iterations, work items are exclusively peer-to-peer. If you want to do any kind of reporting based on hierarchy, you'll need to set up an area or iteration to support it first.

One side-effect of slicing and dicing your large Team Projects is that project email alerts become problematic. The default UI for email alerts only allows you to subscribe to emails at the project level:

On a large Team Project, it's unlikely you would want an email alert when anyone checks anything in under the Team Project. You probably want email alerts for specific areas of the tree.

To do that, you'd normally use the bissubscribe.exe command-line tool, as described on Buck's blog. It seems straightforward enough:

bissubscribe /eventType CheckinEvent /address someone@domain.com 
/deliveryType EmailHtml /server http://teamsystem:8080 
/filter "'Artifacts/Artifact[starts-with(@ServerItem, \"$/TeamProject/A\")]' <> null"

We'd just replace "$/TeamProject/A" with whatever path we're interested in. But there's one small problem: bissubscribe.exe is not installed on the client! It only exists on on the Team Foundation Server, at this path:

C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\TF Setup\bissubscribe.exe

That makes subscribing to events on a large Team Project somewhat.. problematic for the client, at least using the provided GUI. There's not even any way to browse your list of current subscriptions! There is Naren's GUI tool for creating work item subscriptions, but we were unable to quite get it to work.

The good news is that you can copy the bissubscribe.exe tool to the client and run it from there.

Patching Team System to Service Pack 1

Microsoft recently released Visual Studio 2005 Service Pack 1. The update patches any version of Visual Studio, with the exception of the free Express Editions. It also patches any client edition of Team System:

• Visual Studio 2005 Team Edition for Software Testers
• Visual Studio 2005 Team Edition for Software Architects
• Visual Studio 2005 Team Edition for Database Professionals
• Visual Studio 2005 Team Edition for Software Developers

Service Pack 1 fixes tons of bugs in VS 2005, including many in Team Explorer, the essential client piece of Team System. I would install SP1 as soon as is practical for your team. Be warned, however: Visual Studio 2005 Service Pack 1 can be painful to install. It takes massive amounts of disk space and memory to install successfully, and can take longer to install than Visual Studio 2005 itself! As documented on Heath Stewart's blog, these two problems are common. We've experienced them at Vertigo, and I've heard from clients who have run into them as well.

1. You receive the error "File '...' was rejected by digital signature policy". Follow Heath's registry edit workaround.
2. During the SP1 install you run out of disk space. Disable the patch cache to remove redundant file backups during the patch and dramatically speed up the install process. Jon Galloway put together a little batch file which automatically disables the patch cache during the install, then reinstates it after the patch. I highly recommend using this batch file to install SP1.

   reg export HKLM\Software\Policies\Microsoft\Windows\Installer installer.reg
   reg add HKLM\Software\Policies\Microsoft\Windows\Installer /v MaxPatchCacheSize /t REG_DWORD /d 0 /f
   net stop msiserver
   start /wait VS80sp1-KB926601-X86-ENU.exe
   reg delete HKLM\Software\Policies\Microsoft\Windows\Installer /v MaxPatchCacheSize /f
   reg import installer.reg
   net stop msiserver
   del /q installer.reg 2>nul
   

In general, make sure you have tons of free disk space before installing SP1, and set aside a least an hour for the actual install. You do have to babysit it, because it'll prompt you for each update it installs.

There's also a companion Service Pack 1 update for Team Foundation Server as well. It is, thankfully, much easier to install than Visual Studio 2005 SP1. I've had no problems whatsoever installing the TFS SP1 patch, but I do have a few notes on the install.

1. You do not need to patch the server and client at the same time. It's perfectly fine to have SP1 clients talk to a non-SP1 server, or vice-versa. They can be installed completely independently.
2. You must always install KB919156 before SP1, so go ahead and download that first.
3. If you have seperate tiers for build, data, and web, you must install the patch on each tier. It doesn't appear to matter what order you patch them in.

The full list of fixes for TFS SP1 can be found in these two posts (one, two) by Brian Harry.

Good luck and happy patching!