I’ve raised two suggestions on Connect to allow developers more granularity over which build types they receive alerts for. If you’d like this please vote!

Team Build Notification Email Subjects Should Be Customisable

Developers Should Be Able To Subscribe To Alerts For Specific Build Types

Although avoiding a complex branching and merging strategy is best practice it is sometimes difficult even with a simple strategy to visualise exactly where a change is (or has been). Brian Harry has posted about some new features which will make visualising changes in branches much easier.

I’ve been doing some work today on extending the Team Foundation Server UI, for example integrating with Team Explorer and the Pending Changes windows. I came across a number of resources explaining how to achieve this:

How to get the active Team Foundation Server and Project from an Add-In

Extending Team Foundation Server Version Control for Team Build Types Visual Studio integration

How to Write a Team Foundation Version Control Add-in for Visual Studio

Extending VSTS Work Item Tracking UI: Accessing work item UI elements and responding to events

Work Item Tracking v1 Client Extensibility in Visual Studio Team System

A question I’ve had a few times is how can you delete folders from your local workspace without deleting them from the server. This question usually comes up when someone has done a get of a large area and wants to free up some local disk space.

Just deleting the folder using Windows Explorer works but it has a problem, Team Foundation Server still thinks you have that folder, so if you try to get the folder (or one of its children) from source-control in the future then Team Foundation Server won’t download it unless you use Get Specific Version and choose the Force get of file versions already in workspace option.

The solution is to cloak the folder, perform a get on the folder and then remove the cloak. When you do a get of a cloaked folder Team Foundation Server removes the local version from your workspace, thus freeing up your much needed disk space.

To cloak a folder simply edit the appropriate workspace and add an additional folder mapping with a status of Cloaked.

The emails sent by Team Build to notify that a build has completed don’t include the build type that spawned the build. This isn’t normally an issue because the default build numbers used include the build type. However, if you’ve overriden the build number generation you may want to include the build type within the email.

1. On the Team Foundation Server navigate to %ProgramFiles%\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\Services\v1.0\Transforms. This is where all of the email templates are stored.
2. Back up the files BuildCompletionEvent.plaintextXsl and BuildCompletionEvent.xsl. These are the files we’ll be modifying.
3. Edit the BuildCompletionEvent.plaintextXsl file.
4. Immediately below the line Team Project: <xsl:value-of select=”BuildCompletionEvent/TeamProject”/> add the line Build Type: <xsl:value-of select=”BuildCompletionEvent/Configuration”/>.
5. Save the file.
6. Edit the BuildCompletionEvent.xsl file.
7. Immediately below the section:

   <tr>
       <td>Team project: </td>
       <td class=”PropValue”><xsl:value-of select=”TeamProject”/></td>
   </tr>

   Add the section:

   <tr>
          <td>Build type: </td>
          <td class=”PropValue”><xsl:value-of select=”Configuration”/></td>
   </tr>

8. Save the file.
9. Back up the two files you modified. You should do this because when applying a Team Foundation Server service pack these files may be reverted to the original versions.
10. Finally, restart IIS on the Team Foundation Server. You need to do this because these *.xsl files are cached the first time they are read and restarting IIS will refresh this cache.

That’s all there is to it. I haven’t tested this under Team Foundation Server 2008 (yet) but I expect the process will be the same. The more advanced reader will be wondering how I knew that the element that had to be selected was called Configuration, there are two parts to my answer:

1. For each of the events there is an *.xsd file in that directory that specifies all of the elements that are available when that event fires. In this case it is the BuildCompletionEvent.xsd file that we’re interested in.
2. When looking at that file the first element I chose was the one called Type (this seemed logical), however, in my testing this was always blank. After a bit of research I came across a post by Jason Prickett stating the Configuration is the correct element to use.

Compare/merge tools are very much a developer preference so it’s useful that Visual Studio Team System allows you to specify your own compare/merge tool.  What’s even better is that you can have different tools for different extensions, so if you’d like to use a different tool to compare/merge *.xml files then you can do this.

Here’s how:

1. From the Tools menu click Options….
2. Expand Source Control.
3. Click Visual Studio Team Foundation Server.
4. Click Configure User Tools….
5. Click Add.
6. Enter the extension (including the leading full-stop). If you’d like to use the tool for all files then enter “.*”.
7. Select Compare or Merge. If you want to use the tool for both then you must add two entries.
8. Browse for the tool.
9. Enter the arguments to be passed to the tool. To see a list of the available placeholders click the black triangle button.
10. Click OK.

For Araxis Merge you can use the arguments:

• Compare: /title1:%6 /title2:%7 /max %1 %2
• Merge: /title1:%6 /title2:%8 /title3:%7 /max /wait /3 %1 %3 %2 %4

Feel free to leave comments with configurations for other tools.

If rolling the Team Foundation Server Power Tools out to a number of users (which you will need to do if you want to use the check-in policies) you will probably want to run the installation unattended.

There are two tricks:

1. You will need to uninstall the previous version. To do this run:
   msiexec.exe /x /qn {C802488F-CB5F-48BE-BBD2-0C0F9E290E63}
   /x specifies that we are doing an uninstall
   /qn specifies that we want no user interface
   {C802488F-CB5F-48BE-BBD2-0C0F9E290E63} is the Product Code for the Team Foundation Server Power Tools
2. Then you need to install the latest version. To do this run:
   msiexec.exe /i /qb tfpt.msi ADDLOCAL=CLI,VSIP,CHECKINPOLICIES
   /i specifies that we are doing an install
   /qb specifies that we want a basic user interface (just a progress bar)
   tfpt.msi is the path to the tfpt.msi to be installed
   ADDLOCAL=CLI,VSIP,CHECKINPOLICIES specifies that we only want to install tfpt.exe, the Visual Studio add-in, and the check-in policies (we leave out the Best Practices Analyzer [BPA] and the Process Editor [PROCESSEDITOR] because most users don’t need these and they have dependencies on PowerShell and the DSL Runtime respectively)

I used dark.exe from the WiX Toolkit to determine the ProductCode and thanks must go to Hua Chen from Microsoft for helping out with how to exclude the Best Practices Analyzer and the Process Editor.

Brian Harry has pointed out that the TFS 2008 SDK was erroneously excluded from the VS 2008 SDK. They are working on rectifying this but recommend that in the meantime you continue using the TFS SDK in the VS 2005 SDK because there have been very few object model changes.