Buck Hodges

Visual Studio Online, Team Foundation Server, MSDN

September, 2007

  • Buck Hodges

    Team System Web Access for TFS 2008 CTP released


    [UPDATE]  The final version is now available

    Team System Web Access for TFS 2008 Power Tool CTP is now available!

    For TFS 2008, TSWA will continue to be a power tool through the TFS 2008 release.  For the release after that, it will be a part of the regular product.  The final release of the TSWA for TFS 2008 power tool will happen near the time TFS 2008 ships, which we've stated is by the end of this year.

    The big news with this release is the support for custom controls in work item forms.  When you install TSWA, you will find a subdirectory in the installation directory that contains the SDK documentation, which describes the interface, JavaScript functions, etc.  There are also several examples provided, including a checkbox, a work item picker, and a multi-value selector.  You will not be able to use existing custom controls as they are, because those are WinForms based and TSWA requires web-based controls.  However, the same basic concepts apply.  Please try this and let us know what you think!

    We've also fixed a number of bugs and added support for some of the new Team Build functionality in TFS 2008 (queuing builds and viewing the build queue).  This should be a solid release.

    For those of you who remember the need for the TSWA users group in the installation of the TSWA 2005 power tool, you'll be happy to know that is gone.  That was something we had to add to satisfy security requirements, but we've since changed the code to handle the impersonation better such that impersonated user identities no longer need access to any of the local directories for cache files and user settings (i.e., the code reverts to the service account while it accesses those).

    Note that you need to install Team Explorer 2008 on the computer before installing TSWA 2008.  The previous release required Team Explorer 2005.

    Visual Studio Team System Web Access 2008 Power Tool CTP


    Team System Web Access is a free download that will be incorporated into a future release of Visual Studio Team System. You may install it with licensed installations of Team Foundation Server. You must be a licensed user of Team Foundation Server to access Team System Web Access.

    • NEW: Display custom controls on work item forms
    • NEW: view queued builds new, queue new builds
    • Add new work items or edit existing ones
    • Work with any type of work item, including custom ones
    • Add new work item queries or edit existing ones
    • View, download, upload, check-in and check-out documents on SharePoint team portal
    • View reports, export as PDF or Excel
    • Browse source control repositories, download files, view changesets, diffs, histories, and annotated views
    • View build results, start or stop builds
    • Search for keywords in work items


  • Buck Hodges

    Preview of the build notification tray applet power tool for TFS 2008


    [UPDATE 12/21/07]  The build notification tool has now become part of the TFS Power Tools for TFS 2008!  It has new features and quite a few fixes (not to mention that it's a signed binary), so I've removed the attachment from this post.

    We would have loved to have included in TFS 2008 a build notification tray applet along the lines of CCTray for CruiseControl.  However, we didn't have the time in the schedule to do it.  As a result, we're going to be releasing one as a power tool.

    You may remember seeing the spec for this on Jim Lamb's blog.  Swaha Miller, a developer on Team Build, implemented this tool, and I've attached the binary to this post to provide a preview and get your feedback.  Disclaimer: Please note that this is not official software, has bugs, may burn up your computer, etc.  In other words, you accept full responsibility for it if you choose to run it.

    When you run it, you'll see a balloon tip in your system tray (I have my taskbar docked to the right-hand side of my screen).  The applet automatically configures itself to run when you log into your computer.  Don't worry, though.  You get the option of removing that if you shut down the applet.

    Start up balloon

    When you click on the balloon, you'll be able to select which build definitions you would like to monitor.  The list of servers is retrieved from the registry location that Team Explorer stores them.  If you've never used Team Explorer before, there won't be any servers listed.

    Here I'm going to monitor the HelloworldTest builds in the VSTS V2 Plans team project.  You can monitor as many builds as you like and on multiple servers, but I'm just monitoring one build.  I've chosen to be notified when a build is started and finished, regardless of who kicked it off.  Note that you can filter the build definitions if you have a lot to deal with.

    Configure Build Notifications

    It turns out that the last time this build executed, it was successful.  You'll notice the tray applet's icon has a green circle with a check mark in it.

    Last build was good

    Let's kick off a new build and see what happens.  Here's the notification that the build is starting.  The Stop Build link on the "toast" window allows you to stop the build, if you don't want it.  For those of you paying really close attention, you'll notice that this is the .3 build.  I missed capturing a screen shot earlier.

    Build started notification

    Meanwhile, the tray applet's icon changes to show a green triangle "playing" icon, indicating a build is in progress.

    Build is in progress

    When the build completes, you can see that I've broken the build.  By clicking on the popup window, you can view the build details in a web browser.  If you click the little triangle in the upper right corner, you'll get a menu with other options.  In this case, it turns out that the drop location that I specified didn't exist.

    Build failed notification

    Now the applet's icon shows a red circle with an 'X' in it, indicating that the last build is broken.

    Last build was broken

    If you want to learn more about this build, you can double click on the tray applet's icon to pop up the following window.  If you right click on the build, you'll get options to view the details in a web browser, delete it, etc.

    Current Build Status

    I fixed the drop share problem and ran the build again.

    Build partially succeeded notification

    As you can see, the build was only partially successful.  What went wrong?  Well, it's something many of you have experienced.  The compilation succeeded, but the test failed because Visual Studio Team System for Testers isn't installed on the build machine!  We have plans to make installing the unit test framework on your build server much easier in the release after TFS 2008.

    We hope you enjoy using this build notification tray app.  Please let us know what you like and dislike and what features you would like to see in the next version by posting your comments here.


  • Buck Hodges

    TFS 2008: Controlling the number of threads used in uploading and downloading files


    The TFS version control client object model normally uses up to eight threads from the thread pool to upload or download files.  This same mechanism is also used in pending adds: Files are opened to determine whether they are binary or text, so batches are sent to the server while other batches are being examined on disk.  It also uses eight threads.

    Some customers have encountered a problem where a firewall will consider these multiple simultaneous connections to the server to be suspicious activity and block them (e.g., interpret them as a DOS attack).  In TFS 2005 there was no way to control this.

    In TFS 2008 (beta 2 and newer), we added a way to control how many threads are used.  You can control how many threads are used by changing the .config file (tf.exe.config, devenv.exe.config, or your own app's .config, depending on what you are running) and set VersionControl.MaxBackgroundThreads to the number you desire from 0 to 64 (defaults to 8).

    For example, the following will restrict it to two threads.

          <add key="VersionControl.MaxBackgroundThreads" value="2" />

    If you set the maximum number of background threads to zero, the request is made on the calling thread rather than a thread from the thread pool.

    Some customers have reported that they have solved the problem by having the TFS client bypass the network proxy for local (intranet) addresses.  You can do this by changing the settings in IE to bypass the network proxy for local addresses.  Alternatively, you can change this just for TFS by setting the following registry value.  You can set the following in either HKLM (global for the computer) or HKCU (for a particular user on the computer).  Change 9.0 to 8.0 if you are using TFS 2005 rather than TFS 2008.



  • Buck Hodges

    Changing TFS email notifications to link to Team System Web Access


    Neno Loje has written a blog post that shows you the steps to change the links in the TFS work item alert emails into links to work items in TSWA.  The standard links point you to a read-only page, which is not nearly as useful.

    Check it out!

    Changing TFS email notifications to link to Team System Web Access

  • Buck Hodges

    VSTS 2005 and 2008: Building Database Projects with Team Build


    Jon Liperi, a tester on Team Build, has put together the post below that explains a number of the issues around using Visual Studio Team Edition for Database Professionals (DBPro) with TFS Build.  Jon previously worked on the DBPro team, so he knows his way around it quite well.  Here are the issues that he covers.

    • Issue #1: Team Build service account does not have the required SQL Server permissions or cannot connect to SQL Server
    • Issue #2: Values for TargetDatabase, TargetConnectionString, or DefaultDataPath are missing or incorrect
    • Issue #3: The New Build Definition dialog does not provide a “Default” configuration option
    • Issue #4: The Deploy target is not invoked when built via Team Build
    • Issue #5: Database Unit Tests cannot find database project files, data generation plans, or the database instance(s) to be used for running tests when run via Team Build

    This information applies to both the 2005 (8.0) and the 2008 (9.0) versions of VSTS and TFS.

    Building Database Projects with Team Build by Jon Liperi

    Recently, we have seen more questions about building database projects with Team Build. It is absolutely possible to build these project types with Team Build. However, you’ll need to have VSTE for Database Professionals (aka DBPro) and SQL Server installed on the build agent. There are also several known issues. In this blog post, I’ll describe these issues and their workarounds. Please let me know if there are additional issues you encounter or if the work-around steps need a bit of correction by commenting on this blog entry or posting on the Team Build forum:


    To start, I’ll point you to a few links specific to database projects, including some existing documentation around Team Build integration.

    Visual Studio Team System Database Edition (MSDN documentation)

    How to: Deploy Changes using Team Foundation Build (MSDN documentation)

    Visual Studio Team System - Database Professionals Forum

    Issue #1: Team Build service account does not have the required SQL Server permissions or cannot connect to SQL Server

    Database projects create a scratch database on the local SQL Server instance when building. Therefore, the build will fail if the Team Build service account does not have the appropriate permissions on the SQL Server instance running on the build machine. You may see an error message similar to the one below in the build log:

    The "SqlBuildTask" task failed unexpectedly.

    Microsoft.VisualStudio.TeamSystem.Data.Common.Exceptions.DesignDatabaseFailedException: You have insufficient permissions to create the database project. For more information, see the product documentation.

    To resolve this issue, grant the required SQL Server permissions to the Team Build service account. In Orcas, the Team Build service runs by default as NT AUTHORITY\NETWORK SERVICE. A quick way to fix this is to create a SQL login for the service account that has sysadmin privileges. However, if you want to grant only the minimal permissions, detailed SQL Server permissions for DBPro are described here:


    Additionally, you may need to ensure that a necessary registry key, which points to the local SQL Server instance to use for build, exists on the build machine. To configure the build account’s HKCU hive to point to the correct instance, you can either:

    1. Start the Visual Studio IDE as that user. Set the instance name by opening Tools | Options and navigating to Database Tools | Design-Time Validation Database.
    2. Run the following command from a command prompt.
      (Note: You may need to replace 9.0 with 8.0 depending on the version of DBPro you are using.)

      runas /user:<Team Build service account> "REG ADD HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\DBPro\DialogPage\Microsoft.VisualStudio.TeamSystem.Data.DBProject.Settings.DataConnectionOptionsSettings /v DefaultSqlServerName /d <instance name>"

      The value for <instance name> is just the name of the instance. For example, if the instance is “.\SQLEXPRESS”, replace <instance name> with “SQLEXPRESS”. If it is an unnamed instance, enter an empty string.

    Issue #2: Values for TargetDatabase, TargetConnectionString, or DefaultDataPath are missing or incorrect

    Database projects store any non-default values for the TargetDatabase, TargetConnectionString, and DefaultDataPath properties in a <ProjectName>.dbproj.user file which is not checked into version control (as the values may be different for each user). Therefore, these values are missing when built via Team Build resulting in the following error message:

    TSD257: The value for $(DefaultDataPath) is not set, please set it through the build property page.

    To build successfully from Team Build, you must either:

    1. Copy these properties from the <ProjectName>.dbproj.user file and add them to the <ProjectName>.dbproj file for the configuration that you want to build.
    2. Pass these properties as MSBuild command line arguments by entering them in the Queue Build dialog (Orcas only) or by storing them in the TFSBuild.rsp file. For example:
      /p:DefaultDataPath=<path>; TargetDatabase=<databaseName>;AlwaysCreateNewDatabase=true;TargetConnectionString="<connection string>"

    [After this was posted, Peter Moresi, a developer for Microsoft's AdECN Exchange, sent us the following alternative that may better fit your needs.]

    There is also a third alternative.  Using the first solution of copying the properties in the .dbproj file may cause problems when checking out and checking in the project file, depending on how your team works. The alternative is to create, prior to compilation in the build process, a .user file that includes the required settings. This solution is very similar to the solution to Issue # 5.

    1. Create a new file, called $(MSProjectFile).teambuild.user, in the database project that contains the settings for TargetConnectionString, TargetDatabase, and DefaultDataPath. You may also want to include AlwaysCreateNewDatabase so you can explicitly manage this setting for the build.  You'll need to use .user file generated for your project and add the PropertyGroup shown in bold below as the contents for this new file.

      <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
            <FileGroupFileNameList Version="1" xmlns="">
        <PropertyGroup Condition=" '$(Configuration)' == 'Default' ">
          <DefaultDataPath>c:\program files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\</DefaultDataPath>
          <TargetConnectionString>Data Source=localhost;Integrated Security=True;Pooling=False</TargetConnectionString>

    2. Create the file Microsoft.VisualStudio.TeamSystem.Data.TeamBuildTasks.targets as described in Issue #5, Step 4 described later in this post.  Then add the following statements to the end of that file (inside the closing </Project> tag).

        <__TeamBuildUserFile Include="$(MSBuildProjectFile).user"/>
      <Target Name="RenameTeamBuildUserFile">
        <CreateItem Include="$(MSBuildProjectFile).teambuild.user">
          <Output ItemName="TeamBuildUserFile" TaskParameter="Include" />
        <Copy SourceFiles="@(TeamBuildUserFile)" DestinationFiles="@(__TeamBuildUserFile)" />

    3. Modify the .dbproj file and add these elements to the end (inside the closing </Project> tag).  You'll need to change v9.0 to v8.0 if you are using the 2005 (v8.0) release rather than the 2008 release (v9.0).

      <Import Condition="'$(TeamBuildConstants)' != ''" Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\TeamData\Microsoft.VisualStudio.TeamSystem.Data.TeamBuildTasks.targets" />
      <Target Name="BeforeBuild" DependsOnTargets="$(BeforeBuildTeamBuildTargets)"></Target>

    Issue #3: The New Build Definition dialog does not provide a “Default” configuration option

    Database projects do not define Debug or Release configurations. They only define “Default”. When creating a new build definition, you may notice that the only listed options are “Release” and “Debug”. To work-around this, you can either:

    1. Manually type in “Default” in the dialog.
    2. Ensure the “Release” and “Debug” solution-level configurations are set to build the “Default” configuration of the database project.

    Issue #4: The Deploy target is not invoked when built via Team Build

    The default target executed by MSBuild is Build. Therefore, database projects may not deploy by default when built via Team Build. To invoke the Deploy target from Team Build, you must either:

    1. Ensure your solution configuration is set to invoke both the Build and Deploy targets on the database project.
    2. Override AfterDropBuild to explicitly invoke the Deploy target. Instructions for overriding Team Build targets can be found at:
    3. Modify the TFSBuild.proj file to list the individual projects to build and their targets instead of listing the entire solution. For example:
      <SolutionToBuild Include=”foo.dbproj”>
    4. Edit the .dbproj file to make the DefaultTargets in their dbproj file Build;Deploy. For example:
      <Project DefaultTargets=”Build;Deploy”...>
      This would apply outside of Team Build as well, but it would have the desired effect.

    Issue #5: Database Unit Tests cannot find database project files, data generation plans, or the database instance(s) to be used for running tests when run via Team Build

    Database unit tests provide the ability to deploy a database project and/or run a data generation plan prior to running tests. Database unit test projects store the location of the referenced .dbproj and .dgen files as relative paths in the app.config file.

    When building a database project using Team Build, the output and source files are stored in a different directory structure on the build machine. The test files are located in a TestResults folder while the source files are located in a Sources folder. When the unit tests are run from the TestResults folder, the relative path to the referenced .dbproj and/or .dgen files in the <assemblyname>.config file is no longer correct. This causes the tests to fail with one of the following messages:

    Database deployment failed. Path ‘<path>\Database1.dbproj' is not a valid path to a database project file.

    Data Generation failed. Path '<path>\Data Generation Plans\DataGenerationPlan1.dgen' is not a valid path to a data generation plan file.

    Additionally, the app.config file also stores connection string information that points to the SQL Server instance to be used for running tests. If the connection strings are not valid when the tests are run from the build machine during a Team Build, the unit tests will fail with the following message:

    An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections.

    (Note that you may want the connection string to change depending on if they are running locally or through Team Build. For example, you may want tests to use your local SQL Server instance during development but use a remote shared instance when running via Team Build. The solution to this issue can also be used to achieve this result.)

    To fix this issue, users need to manually create an app.TeamBuild.config file with the correct path locations and connection strings to be used when builds are created via Team Build. This file will then be renamed to <AssemblyName>.config through a post-build target, overwriting the .config file that contains the incorrect values.

    1. Create a file named app.TeamBuild.config by copying the existing app.config in your unit test project. Add it to your unit test project in version control.
    2. In the app.TeamBuild.config file, change the relative path to the .dbproj and .dgen files by adding a folder level for the Sources folder and a subfolder with the same name as the solution. For example,

      "..\..\..\Database1\Data Generation Plans\DataGenerationPlan1.dgen"

      "..\..\..\Sources\Database1\Database1\Data Generation Plans\DataGenerationPlan1.dgen"



      Additionally, you can modify the connection strings in the app.TeamBuild.config to the strings that should be used from the Team Build machine. Check the changes back into version control.
    3. Check out the unit test project file and modify the end of the file to include these lines right before the </project> tag. Check the changes back into version control.
      (Note: You may need to replace v9.0 with v8.0 depending on the version of DBPro you are using.)

      <Import Condition="'$(TeamBuildConstants)' != ''" Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\TeamData\Microsoft.VisualStudio.TeamSystem.Data.TeamBuildTasks.targets"/>

      <Target Name="AfterBuild" DependsOnTargets="$(AfterBuildTeamBuildTargets)">

    4. On the Team Build machine, create a file with the code below and name it Microsoft.VisualStudio.TeamSystem.Data.TeamBuildTasks.targets. Save the file in folder %Program Files%\MSBuild\Microsoft\Visual Studio\v9.0\TeamData
      (Note: You may need to replace v9.0 with v8.0 depending on the version of DBPro you are using.)

      <?xml version="1.0" encoding="utf-8"?>

      <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

      <UsingTask TaskName="DataGeneratorTask" AssemblyName="Microsoft.VisualStudio.TeamSystem.Data.Tasks, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>


        <__TeamBuildConfig Include="$(OutDir)$(TargetFileName).config"/>

      <Target Name="RenameTeamBuildConfig">
        <CreateItem Include="app.teambuild.config">
          <Output ItemName="TeamBuildAppConfig" TaskParameter="Include" />
        <Copy SourceFiles="@(TeamBuildAppConfig)" DestinationFiles="@(__TeamBuildConfig)" />

      <Target Name="DataGen">
         Verbose="$(Verbose)" />


    [UPDATE 8/29/08] I've added another alternative to solving issue #2 courtesy of Peter Moresi.

  • Buck Hodges

    We need your help: Patches to apply to TFS 2008 beta 2


    Brian has written a post, Practicing servicing for TFS 2008, with links to six patches.  We need your help in installing these patches and letting us know what issues you run into.  The goal is to make servicing TFS 2008 better than it was with TFS 2005.  Folks using web projects under version control in Visual Studio will notice fixes for several issues.

    I want to point out the patch for the build agent (aka Build SKU) in particular (the patch does not apply to Team Explorer).  This patch will update a couple of assemblies (DLL files) on the build computer (aka build machine or build server) and the Microsoft.TeamFoundation.Build.targets file.  What this change does is change the build process such that the workspace name used by the build does not include the name of the build definition.  Before the fix, renaming the build definition would result in the build failing due to an error about the path to be used already being mapped in a different workspace, which was the workspace with the old build definition name in it.

    KB942082 - Visual Studio 2008 Team Build Beta 2 - Builds fail after renaming the build definition

    The patching process won't replace the Microsoft.TeamFoundation.Build.targets file if it has been changed.  While you aren't supposed to change that file, some folks have.  If you have changed it and the patching process doesn't replace the file with the updated one from the patch, your build will fail.  Working around that just requires renaming the targets file and re-applying the patch.  If this happens to you, please let me know.  I'd like to argue for the patch process to rename the old one and always place the new one on disk.  As such, I'd like to have some sense for how many folks are affected by this.

  • Buck Hodges

    Dave McKinstry on Build in TFS 2008


    Dave McKinstry has written a couple of posts on his experiences with Team Build in TFS 2008.  In Introduction to Team Build 2008 for Team Build 2005 Users, he goes over the major new features and how certain things like handling workspace mappings are improved over TFS 2005.  His post includes screenshots and more.  It's a great companion to the basic guide post.  I can't help but quote a couple parts that I enjoyed the most.

    If you haven't already gotten a chance to play with TFS 2008 (Beta 2), I recommend it.  My experience is that it is solid and seems to work better than the RCs worked for the 2005 release.  My primary interest is in the Team Build enhancements, although there are a few other interesting TFS 2008 features such as Destroy and the integration of key TFS Power Tool elements.


    There are certainly other changes in Team Build 2008, but this should summarize all of the significant change.  I rarely recommend prerelease software for any of my clients.  However due to the vast enhancements in Continuous Integration support (i.e., triggers, queuing and retention policies), both my company and one of my customers are using TFS 2008 Beta 2 and it's go-live license.  Note that for my client, the users are still using Visual Studio 2005 and Team Explorer 2005...  but the Team System back end is all 2008!

    He also writes about considerations in using TFS 2008 with VS 2005 clients.  The post points out how it is important to have at least someone on the team who also has VS 2008 installed (or at least Team Explorer 2008) to be able to access and configure the new features available on TFS 2008.  Once someone has configured build definitions for CI, for example, folks using VS 2005 automatically get the benefit of CI (even though they can't see the build queue, for example).

Page 1 of 1 (7 items)