Team System

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!