Buck Hodges

Visual Studio Online, Team Foundation Server, MSDN

September, 2006

  • Buck Hodges

    How to handle "The path X is already mapped in workspace Y"


    This has come up before on the forums, but I don't think I've ever posted about it here.  Today I saw a reference to the TFS Workspace Gotcha! post in today's Team System Rocks VSTS Links roundup.  There's a command to deal with the problem, but it's not obvious.

    Here's the post.

    I have been working with a team that has recently migrated a TFS source project from a trail TFS to a full production server (different server).  They disconnected their solution from source control (removes all the SCC stuff from .sln) files and then tried to add to the new TFS.

    However, they were getting weird errors.

    I suggested that they might not have their workspace mapped correctly to the new TFS project.

    When they tried to map the workspace, they got the following error:

    The Path <local path> is already mapped in workspace <machine name [old tfs server]>

    Hmm, I thought we removed all the source stuff?

    Turns out that the workspace mappings are stored in a file called:

    VersionControl.config under the users local settings/application data directory.

    I could find no way (other than manually editing the forementioned file) to remove the workspace mapping from that local folder to the other TFS server (which is no longer in usage).

    Anyway, once that was done, all was good in the world.

    Thanks go out to Kevin Jones for his excellent post on Workspaces in TFS.

    While deleting versioncontrol.config will clear the cache, we've actually got a way to do it from the command line.  The command "tf workspaces /remove:*" clears out all of the cached workspaces (it only affects the cache file).  You can also specify "/s:http://oldserver:8080" to clear out only the workspaces that were on the old server. The MSDN documentation for the workspaces command is at http://msdn2.microsoft.com/en-us/library/54dkh0y3.aspx.

    The reason that he hit this is due to switching servers. Every server has a unique identifier, which is a GUID. Each local path can only be mapped in a single workspace, and the versioncontrol.config cache file is the file that the client uses to determine what server to use when given a local path (e.g., tf edit c:\projects\BigApp\foo.cs).

    He originally had a workspace on the old server that used the local path he wanted to use with the new server. Let's say that's c:\projects. When he tried to create the new workspace on the new server (GUID2) that he also wanted to map to c:\projects, the client saw that the old server (GUID1) was already using that local path. Since the IDs for the servers did not match, the client complained that c:\projects is already mapped to the old workspace on the old server.

    The client uses the server's ID as the real name of a server.  The reason is that the name could change, either because an admin changed the server's name or because a user needs to access the server through a different name depending on the connection (intranet vs. internet).  The only "name" guaranteed not to change is the ID.  So, when presented with a different network name, the client requests the ID from the server and compares it to the IDs listed in the versioncontrol.config cache file.  If the ID matches one of them, the client simply updates the existing entry to have the new name, so that subsequent uses of the new name do not incur an extra request to check the ID.  If the ID does not match any of them, then the server is different than any of the servers in the cache file.

    The error message looks like it's showing the machine, but it's actually showing the workspace name.  The reason for the confusion there is that the version control integration in VS creates a default workspace that has the same name as the machine.

    The problem will not occur if you upgrade the same server (i.e., you don't create a new server), as an upgraded server still has the same ID.

    Though /remove isn't mentioned (part 2 does mention the error message at the end), you can check out Mickey Gousset's workspace articles for more information on workspaces and managing them.

    tags: , ,

  • Buck Hodges

    TFS API documentation is now on the MSDN web site


    Rob Caron mentioned that the SDK documentation is now on the MSDN web site.  That SDK documentation includes the Team Foundation Server API documentationLast year I pointed out where to find the version control documentation in the massive download that is the VS SDK, but you don't need to do that now.

    So, the good news is that the documentation that we have is much more accessible.  The bad news is that it's still pretty thin.  Folks are working on that, but it's going to take time -- the API is pretty large.

    Version Control API

    Here are some pointers to some key classes for version control, which you can see used in code in the basic version control API example.

    • TeamFoundationServer – this is not a version control class, but it is the root object from which you obtain a service, such as version control (VersionControlServer)
    • VersionControlServer – this is the primary interface to the version control server for operations and queries that are not specific to a workspace, such as getting a list of workspaces in the repository or setting permissions
    • Workspace – this object represents a workspace and is used to pend changes, check in changes, and perform queries specific to a workspace
    • Workstation – this object represents the current computer and manages the workspace cache, which contains the list of local paths in each workspace

    One thing to note is the format of each URL.  If you know the fully qualified name of the class that you are after, you can go straight there.  For example, here's the link for Microsoft.TeamFoundation.Client.VersionControlServer: http://msdn2.microsoft.com/en-us/library/Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer.aspx.

    You'll notice a lot of exception classes in version control Client namespace.  They only really matter to you if you want to handle a very particular exception, which is generally quite rare.  If you are interested in catching and handling version control exceptions, you can simply catch the base exception class, VersionControlException.  The most important thing about the exceptions is that the message in the exception is intended for display to the end user, so feel free to just display the message from the exception.

    You won't find any documentation on the version control GUI controls, because they aren't public.  In a future release, we'll provide public GUI classes.  If you are writing a VS add-in, you can find documentation on using some of the GUI controls inside of Visual Studio 2005 in Ed's post.

    You can find examples of using the API in the post, Links to code samples.

    Team Build API

    The Team Build API is there as well.  You'll want to skip most of the classes in the Microsoft.TeamFoundation.Build.Common namespace, as they aren't that useful.  In fact, many of them have been marked as deprecated in post-v1 code.  For example, there's a BuildData class in there, but you can't really use it (no public methods take it as input).  You need the BuildData class that the proxy uses.

    So, the namespace to focus on is Microsoft.TeamFoundation.Build.Proxy.  This namespace contains the classes that you need to use to communicate with the server, such as BuildData.

    Here are pointers to the key classes in Team Build.  Everything in the Proxy namespace was generated by wsdl.exe, so you won't find any documentation with these classes.  They are just the bare proxy classes used to communicate directly with the Team Build web service.

    • TeamFoundationServer – this is not a Team Build class, but it is the root object from which you obtain a service, such as BuildStore or BuildController
    • BuildStore - this class is used to add, delete, and access build data
    • BuildController - this class is used to start and stop builds

    We've been working on adding a client object model for Team Build that will provide you with the same types of capabilities you get from the version control and work item tracking object models.  While it's not something that will help you today, you can look forward to it in a future release.

    As with version control, all of the GUI controls are private.

    Work Item Tracking API

    Here are some of the key classes in work item tracking.

    • TeamFoundationServer – this is not a work item tracking class, but it is the root object from which you obtain a service, such as WorkItemStore
    • WorkItemStore - this class represents the work item server and is used to get work items, execute queries, and import and export lists
    • WorkItem - this class represents a work item and is used to create and modify work items

    Work item tracking does expose some of the GUI controls in version 1.  You'll find the documentation in the Microsoft.TeamFoundation.WorkItemTracking.Controls namespace.  If you decide to do much with WIT controls, I highly recommend Naren Datha's blog, especially the article on work item tracking client extensibility and how to configure the WIT OM for a web app.

    Power Toys

    The Team Foundation Server power toys that were released yesterday were written using these classes.  Yes, the latest power toys do make use of some GUI classes that aren't public in v1, but they use the same object model API that's available to you.  In fact, the older tfpt.exe release used only the public API and re-implemented the dialogs where it needed them (the idea being that we might release the source code in the future, but that never happened).  Hopefully, we'll see more community-developed tools, like the TFS tools on CodePlex, using the API.

    Speaking of the power toys, Soma wrote a post today about the TFS power toy release.  He's my boss's boss's boss's boss's boss's boss.  That translates to corporate VP -- the man who runs the Developer Division.

    tags: , , , , ,

  • Buck Hodges

    Sample reports that use the TFS reporting feature


    If you are interested in the TFS reporting feature, you may want to check out the sample reports in the zip file attached to the following blog post.

    Sample Team System Reports

    This attachment contains a variety of samples, experiments and untested reports for use with the Team Foundation Data warehouse. There is a brief overview document describing the reports and how to deploy them.

    zip file: TFS Reporting Samples.zip

    Here's what you'll find in the zip file.  If you have any questions or have feedback for the team, be sure to post in the MSDN TFS Reporting Forum.

    C:\msdown\TFS+Reporting+Samples>tree /F
    Folder PATH listing for volume IBM_PRELOAD
    Volume serial number is 002B0067 18A4:2518
    │   Installing the Sample Reports.doc

    ├───Box Reports
    │   └───Box Reports
    │       │   Box Reports.sln
    │       │
    │       └───Box Reports
    │               Actual Quality vs Planned Velocity.rdl
    │               Box Reports.rptproj
    │               Box Reports.rptproj.user
    │               Bug Rates.rdl
    │               Bugs by Priority.rdl
    │               Bugs Found Without Corresponding Tests.rdl
    │               Builds.rdl
    │               Issues and Blocked Work Items.rdl
    │               Load Test Comparison.rdl
    │               Load Test Detail.rdl
    │               Load Test Summary.rdl
    │               Load Tests.rdl
    │               Project Velocity.rdl
    │               Quality Indicators.rdl
    │               Reactivations.rdl
    │               Regressions.rdl
    │               Related Work Items.rdl
    │               Remaining Work.rdl
    │               Requirement Details.rdl
    │               Requirements Test History and Overview.rdl
    │               Tests Failing without Active Bugs.rdl
    │               Tests Passing with Active Bugs.rdl
    │               TfsOlapReportDS.rds
    │               TfsReportDS.rds
    │               Triage.rdl
    │               Unplanned Work.rdl
    │               Work Item with Tasks.rdl
    │               Work Item with TestResults.rdl
    │               Work Items.rdl

    ├───Portal Reports
    │   │   Portal Reports.sln
    │   │
    │   └───Portal Reports
    │           Bug Rates.rdl
    │           Copy of Quality Indicators.rdl
    │           Issues and Blocked Work Items.rdl
    │           Portal Reports.rptproj
    │           Portal Reports.rptproj.user
    │           Project Velocity.rdl
    │           Quality Indicators.rdl
    │           Reactivations.rdl
    │           Remaining Work.rdl
    │           TfsOlapReportDS.rds
    │           TfsReportDS.rds
    │           Triage.rdl
    │           Unplanned Work.rdl

    ├───Sample Reports
    │   │   Sample Reports.sln
    │   │
    │   └───Sample Reports
    │           7 Day ZBB.rdl
    │           Area Overview.rdl
    │           Code Coverage.rdl
    │           Files by Directory.rdl
    │           Files by Person.rdl
    │           Files by Priority.rdl
    │           Files by Type.rdl
    │           Issues and Risks.rdl
    │           Project Schedule.rdl
    │           Projection.rdl
    │           Quality Indicators - Portal.rdl
    │           Quality Indicators.rdl
    │           Reactivations and Resolutions.rdl
    │           Report Gallery.rdl
    │           Sample Reports.rptproj
    │           Sample Reports.rptproj.user
    │           Source Code Details.rdl
    │           Source Code Overview.rdl
    │           Task Burndown.rdl
    │           Test List.rdl
    │           Tests by Category.rdl
    │           TfsOlapReportDS.rds
    │           TfsReportDS.rds
    │           Work Item List - Point in Time.rdl
    │           Work Item List.rdl
    │           Work Item Revisions.rdl
    │           Work Items.rdl

    ├───TFS Report Examples
    │   │   TFS Report Examples.sln
    │   │
    │   └───TFS Report Examples
    │           Related Work Items.rdl
    │           Related Work Items.rdl.data
    │           TFS Report Examples.rptproj
    │           TFS Report Examples.rptproj.user
    │           TfsOlapReportDS.rds
    │           TfsReportDS.rds
    │           Work Item Chart.rdl
    │           Work Item Chart.rdl.data
    │           Work Item List.rdl
    │           Work Item List.rdl.data
    │           Work Item Trend.rdl
    │           Work Item Trend.rdl.data

    ├───Warehouse Status
    │   │   Warehouse Status.sln
    │   │   Warehouse Status.vssscc
    │   │
    │   └───Warehouse Status
    │           Deployed Reports.rdl
    │           Query Execution History.rdl
    │           Query Execution History.rdl.data
    │           Report Execution History.rdl
    │           ReportServer.rds
    │           TfsOlapReportDS.rds
    │           TfsReportDS.rds
    │           TfsTeambuild.rds
    │           TfsTrace.rds
    │           TFSVersionControl.rds
    │           Warehouse Load Rates.rdl
    │           Warehouse Status.rdl
    │           Warehouse Status.rptproj
    │           Warehouse Status.rptproj.user
    │           Warehouse Status.rptproj.vspscc
    │           Work Item Load Status.rdl
    │           WorkItemTracking.rds

    └───Work Item Overview
        │   Work Item Overview.sln
        └───Work Item Overview
                Work Item by Priority Detail.rdl
                Work Item by Priority.rdl
                Work Item List.rdl
                Work Item Overview.rdl
                Work Item Overview.rptproj
                Work Item Overview.rptproj.user

    tags: ,

  • Buck Hodges

    TFS tools on CodePlex


    I ran two searches on CodePlex to see what folks are developing for TFS.  One search was for "TFS" and the other was for "Team Foundation," which I hope would be enough to catch them all.  The second search only yielded one additional project (Time Tracker).

    It's always cool to see what folks come up with.  Highly-motivated individuals and groups can extend TFS in really meaningful ways.  If you start a project for TFS, contact me when you have a usable release, and I'll mention it in a post.

    The one highlighted in bold have useful releases that you can download today.

    Project TFS Code Review Workflow

    TFS Code Review Workflow This project is a combination of a Code Review Work Item and a Code Review Check-in Policy. The check-in policy doesn’t allow a check-in unless it has an associated Code Review work item, and that work item is set to approved. Only people in a TFS group named [Project]\Code Reviewers can set an item to approved. Workflow: 1. Dev finishes code and wants it reviewed ...

    Project TFS File Sync

    Web Service for receiving notification of TFS check-ins and copying specified files to locations like UNC paths or SharePoint servers.

    [Note: This is like the shadow folders feature from VSS.  It's quite a bit more sophisticated than the Windows task scheduler approach.]

    Project TFS Source Code Version Tree Browser

    This project aspires to create a Version Tree Browser for Team Foundation Server allowing for the visual presentation of branches, merges and version information. The exact format and requirements will be determined as part of this project based on published best practices, similarly mature related product features and TFS version control specific feature sets.

    Project TFS Plug-in for CruiseControl.NET

    A plug-in to allow communication with Team Foundation Server for the popular open source build automation tool CruiseControl.NET

    Project Team Foundation Server Administration Tool

    Member of the Power Toys for Visual Studio Collection - TFS Admin Tool allows a Team Foundation Server administrator to quickly add and modify user permissions to all three platforms utilized by TFS through one common interface.

    Project TeFoSe.Net

    This project will be a Team Foundation Server Client GUI with extended functionality. The GUI will look like the familiar Source Safe GUI offering developer specific features for queries against TFS.

    Project TeamPatter

    TeamPatter is a TFS integrated messaging tool that allows for communication with any user accessible via Windows Live Messenger or classic MSN messenger. The integration with TFS comes in the form that from within workitem screens or via commands used directly in the messenger window, IM conversations on work items and potentially additional artifacts can be stored with the work items and visible ...

    Project Turtle

    Turtle is a free, open source client for Microsoft Team Foundation Server source control services. It is an alternative to the VSTS plugin for Visual Studio, or for those who may be using using TFS for projects not compatible with Visual Studio.

    Project Automaton

    Automaton is a Continuous Integration engine optimized for Team System and Team Builds. Included is the TeamFoundationExtensions class library which includes helpers and tasks for TFS and MSBuild.

    Project Team Foundation Time Tracker

    Team Foundation Time Tracker is small utility for tracking work time on any type of work item in Team Foundation Server

    tags: , ,

  • Buck Hodges

    TFS API: How to choose between TeamFoundationServerFactory.GetServer() and the TeamFoundationServer constructor


    Occasionally the question of whether to use the TeamFoundationServerFactory.GetServer() method or the TeamFoundationServer constructor comes up, and someone recently asked this question on an internal list.  The answer depends on the needs of the application that you are writing.  In this post, I'll discuss the main differences between the two.

    If you have an application where different parts of the code will need to access the same TeamFoundationServer object (say you need to hook up event handlers to the same VersionControlServer object that the rest of the code is using) but only have the name/URL of the server, then the TeamFoundationServerFactory is the correct choice. The TeamFoundationServerFactory caches the TeamFoundationServer objects it creates and always returns a cached TeamFoundationServer object if one matching the request exists. Those cached objects are indexed only by server URL, which is why there is no way to specify the credentials in the GetServer() method. Every time you request the TeamFoundationServer object for http://yourserver:8080, for example, via TeamFoundationServerFactory.GetServer(), you will get the same exact instance, and thus no chance to connect to the same server with different credentials.

    The Team Explorer needs this type of behavior and is why TeamFoundationServerFactory exists. The different parts of the code shouldn't pop up additional login dialogs and yet the code wouldn't know how to retrieve the existing TFS object from a cache whose key included the credentials without first asking the user what credentials to use (there are also complications in dealing with CredentialCache objects; you can read more about CredentialCache objects in the post, Authentication in web services with HttpWebRequest).

    However, if you want to connect to the same Team Foundation Server with different credentials, you must use the constructor. For example, you connect to server A as users X and Y.

    TeamFoundationServer tfsX = 
    new TeamFoundationServer("http://serverA:8080",
    new NetworkCredential(userX, passwordX, domain)); TeamFoundationServer tfsY =
    new TeamFoundationServer("http://serverA:8080",
    new NetworkCredential(userY, passwordY, domain));

    The command line, tf.exe, is an example of an application that can do that via command files containing commands with /login options specifying different users.  For example, you could execute the following by saving the commands in a file called cmd.tfc and running tf @cmd.tfc.  These two commands execute within the context of one running instance of tf.exe, which means tf.exe must use the constructor.

    edit foo.cs /login:userX,passwordX
    perm $/blah/foo.cs /deny:read /login:userY,passwordY

    If you don't have either of these requirements and just need a TeamFoundationServer object to do something, you could choose either.  You'll find examples of both in this collection of code that uses the API.  Personally, I tend to use the constructor for utility apps and examples, but there's no profound reason behind it.

    If you need to prompt the user for credentials to connect to the server, see the post, How to get the login dialog when using the Team Foundation Server API.  The example uses the constructor, but you can also pass the credential provider to the TeamFoundationServerFactory.GetServer() method.

    tags: , ,

  • Buck Hodges

    Adding a path filter to a CheckinEvent subscription using bissubscribe


    This week, a couple of people asked (forum post 1 and forum post 2) how to subscribe to the CheckinEvent notification when there's a checkin under a particular tree.  The first person wanted to filter by path in order to kick off continuous integration.  The second person wanted to filter by path for email subscriptions.

    Here's the command line that I used to configure an email notification for a path.  I've changed the email address (someone@microsoft.com), the server name (http://MyVstfat01:8080), and the path ($/TeamProject/A) from their original values, but it's otherwise what I've used to create a successful subscription.

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

    The difference for CI would be the delivery type and address.  With that changed, the following should work (I confess I didn't try this to verify it, but it's based on the subscription in Jeff Atwood's continuous integration post).

    bissubscribe /eventType CheckinEvent /address http://tsweb01:8080/ci/notify.asmx /deliveryType Soap /server http://MyVstfat01:8080 /filter "'Artifacts/Artifact[starts-with(@ServerItem, \"$/TeamProject/A\")]' <> null"

    However, the expressions that I just wrote won't work reliably.  Why? 

    Unfortunately, using server path comparisons is not as simple as it should be.  What happens is that the version control server uses the workspace mappings of the user checking in the changes to construct the paths.  So if the person checking in $/teamproject/foo/bar.cs uses a server path of $/TeAmPrOjEcT/Foo mapped to c:\project\foo, then the path that will be compared in the filter expression will be $/TeAmPrOjEcT/Foo/bar.cs.

    Why is this a problem since the version control server is case insensitive?  Well, the problem is that the filter expressions are evaluated using XPath, and XPath is case sensitive.

    So, version control constructs server paths used in checking in changes by using the user's workspace mappings, XPath is case sensitive, and not every user types in the paths the same way when creating workspace mappings (e.g., $/MyProject/Foo vs. $/myproject/foo).  The result is that when using the expressions above you'll only get notifications when the user checking in uses the same casing that you do for the paths.

    Fortunately, XPath 1.0, which is what the server uses, provides the translate() function.  The translate() function will convert characters in the first string to the corresponding characters in the second string.  For example, translate("$/A/b/C", "ABC", "abc") will return "$/a/b/c". You can read more about it in the XPath 1.0 documentation.

    So, that means the filter expressions must get more complex in order to work in all circumstances.

    bissubscribe /eventType CheckinEvent /address someone@domain.com /deliveryType EmailHtml /server http://yourserver:8080 /filter "'Artifacts/Artifact[starts-with(translate(@ServerItem, \"ABCDEFGHIJKLMNOPQRSTUVWXYZ\", \"abcdefghijklmnopqrstuvwxyz\"), \"$/teamproject/a\")]' <> null"

    Here's how it works.  It still uses the XPath starts-with() function, but the first argument to that function is now the output of the translate() function.  The translate() call takes all upper case letters in the English alphabet and converts them to the corresponding lower case letters in the input string from the server, @ServerItem.  In the original filter expression, I specified $/TeamProject/A.  However, now that everything is being comverted to lower case, it must be written as "$/teamproject/a" in order to work.

    You would need to make a similar adjustmet to the SOAP subscription as well.

    If you want to be notified of all checkins for $/teamproject/a where the files have some particular file extension, such as .resx, you would need to use a substring and string-length in the expression as follows.

    bissubscribe /eventType CheckinEvent /address someone@domain.com  /server http://yourserver:8080 /deliveryType EmailHtml /filter "'Artifacts/Artifact[starts-with(translate(@ServerItem, \"ABCDEFGHIJKLMNOPQRSTUVWXYZ\", \"abcdefghijklmnopqrstuvwxyz\"), \"$/teamproject/a\")]' <> null AND 'Artifacts/Artifact[substring(translate(@ServerItem, \"ABCDEFGHIJKLMNOPQRSTUVWXYZ\", \"abcdefghijklmnopqrstuvwxyz\"), 1 + string-length(@ServerItem) - 5) = \".resx\"]' <> null"

    Naren Datha posted a nice summary of links for information on subscribing to events.

    NOTE:  There's now a subscription editor in the Team Foundation Power Tools (July '08 and newer) that Naren wrote.  Look for a new Alerts node in Team Explorer under the team project.  I highly recommend it!

    [UPDATE]  I should also have mentioned that for those of you trying to filter the builds, check out Filtering the builds listed in work item tracking.

    [UPDATE 2/2/08]  I've had to change this post significantly to explain how to create subscriptions with filters that will work reliably because XPath is case sensitive, and the version control server does not force a consistent casing of the paths in the changeset.

    [UPDATE 8/22/08]  Added an example of getting notifications for files with a particular extension and added a note about the new alerts editor in the latest power tools release.

    [UPDATE 1/03/09]  Added slashes to escape the unescaped quotation marks in the last bissubscribe call.

    tags: , , ,

  • Buck Hodges

    More power: New power toy release (tfpt) includes VSS-style project difference!


    [UPDATE 8/9/07]  I fixed the broken link to the power tools page.

    Brian Harry announced the latest release of the Team Foundation Power Toys in the post, New TFS Power Toys Available!.  In his post he gives a quick description of each of the new commands and the major enhancements.

    One of the most important aspects of this release is that tfpt is no longer buried in a 300 MB download.  Here's the new slim and trim 1 MB download: http://go.microsoft.com/?linkid=5422499.  That's a 300-fold improvement!  Don't expect that kind of improvement in the next release.  ;-)

    After you install the power toys, you will find tfpt.exe in C:\Program Files\Microsoft Team Foundation Server Power Toys.

    While Brian gives you an overview of everything, I wanted to point out a few things in particular.

    Work Item Tracking commands

    Included in this release is a pair of tfpt commands for work item tracking: query and workitem.  These were actually done back in the early spring (Jason Prickett wrote them back when he worked on WIT), but they didn't make it into the binary that went into the VS SDK and that binary never got updated after February.  Thankfully, that's all in the past now.

    So what's so cool about a command line for work item tracking?  Well, it gives you a great way to be able to create or modify work items from scripts.  Or maybe just bulk assign all of your work items to someone else.  The commands allow you to run stored queries, run arbitrary WIQL queries, create new work items, update existing work items, output work items in XML, upload and download attachments, and more.

    Here are the examples from the help for the workitem command.  Unfortunately, the help produced by the command may be a little confusing because it looks like it takes an option called /fieldvalues and an option called /fields.  The correct option is /fields.

    Creating a new Bug work item with a title of 'New' and assigned to Jason
    tfpt workitem /new project1\Bug /fields:"Title=New;Assigned To=Jason"

    Updating work item 123 with field values from a file
    tfpt workitem /update 123 /fields:@myFieldValues.txt

    Updating all work items assigned to me to be assigned to Jason (uses Query)
    tfpt query /format:id "project1\public\My Work Items" | tfpt workitem /update @ /fields:"Assigned To=Jason"

    Whenever you specify "@" with the /update option of the workitem command, it treats what it reads from standard input as arguments.  So, that last example produces a list of work item IDs from the query command that are then updated to be assigned to Jason.

    If you run these commands from a directory that's mapped to a workspace, you don't need to specify the server.  Otherwise, you can use /s:http://yourserver:8080 to specify the server.


    The online command gets a new option, /diff, that was added by Michal Malecki, a developer on the version control team.  It checks the MD5 hash code for writable files and pends an edit only on files that are different.

    Also, the /nuke option has been renamed to /purge.  The functionality is unchanged.


    The history command is in the old release as well, but I don't think I've ever mentioned why it is significant.  The power toy version is a copy of the regular tf.exe history command, but it has a /followbranches option added by Bill Tutt, a developer on the version control team.  The /followbranches option causes the history command to include the history of any branch ancestors of the file being queried.  Here's an example.

    D:\code\CommandLineBuild>tfpt history /followbranches main.cs
    Changeset Change               User          Date       Comment
    --------- -------------------- ------------- ---------- -----------------------
    102025    branch               somedev       7/29/2006  Branching to create nex

    $/Code/v2/CommandLineBuild/Main.cs;C102025 was branched from $/Code/v1/CommandLineBuild/Main.cs;C101367:

    Changeset Change               User          Date       Comment
    --------- -------------------- ------------- ---------- -----------------------
    101367    edit                 somedev       7/27/2006  fixed a bug
    11367     add                  somedev       5/25/2005  Adding the initial supp

    This command only looks at branches, not baseless merges (the code uses QueryBranches() and QueryHistory() in a loop).

    TreeDiff (VSS-style project difference)

    Here's what so many of you have been waiting for.  A huge number of users have given us feedback that they want a VSS-style project difference GUI.  Sure, there are code samples, but now you can have the real thing!  This was written by one of our summer interns, Taylor, and he did a great job (some of you may recall that tfpt.exe and the first set of commands were written by Philip, one of our summer interns last year).  Brian's post has this screenshot.

    Brian's post also includes information on the new bind command and updates to the annotate command.

    tags: , ,

  • Buck Hodges

    How to measure performance using the web service performance dialog


    You may have read about the Team Foundation activity log, which is a database table containing the web service requests executed by the server (turning it on, interesting queries, and more interesting queries).  You may have also seen posts about turning on tracing, both server tracing (see Patrick Carnahan's first response) and client tracing (see my first response, or the commented-out block in tf.exe.config).  Tracing produces tons of info, and it can be really useful for solving difficult issues.

    What if you just want a convenient way to see the web service calls your application (or ours) makes?  The performance dialog is a very convenient way to do it.  James Manning and I put it and the underlying infrastructure in place about a year before TFS shipped to make it easy to find and fix performance issues, particularly on the client.

    The dialog is included in the Team Foundation client assemblies.  It must be registered as a trace listener in the application's .exe.config file and uses the information available in the client-side tracing to display web service calls.  In the dialog, you'll see how long each call takes, the number of calls made, the average time for a call, and more.

    Here's a screen shot.

    The WebService column usually shows the name of the web method followed by the service being contacted.  For example, "GetMetadataEx2[Wor]" is the GetMetadataEx2 web service method being called on the Work Item Tracking service.  All times are reported in milliseconds.

    The three-letter designation after the web service method name consists of the first three letters of the service name.  Here's a list of what you'll see.

    • Wor - work item tracking
    • Ver - version control
    • Wss - SharePoint
    • Rep - reporting
    • Ser - core Team Foundation services, including the security and team project services
    • Bui - Team Build

    In some cases, you will not see the web method name, such as the case with the AsyncSharepoint call above, where the tracing mechanism couldn't determine the name of the call (it looks for the method name at a particular point in the stack frame).  The other case where this happens is when files are uploaded and downloaded by version control.  In those cases, you'll see Ver-Upload or Ver-Download and the name of the file involved.

    The top section of the dialog shows the aggregated information.  The bottom section of the dialog shows the list of web service methods in the order in which they were called, the elapsed time in milliseconds, and the time of day when the method completed execution.  If the method has not completed, it will display "Running" for the completion time.  If you move the mouse over the entries in the bottom section, a tool tip will show you the stack trace, so you can see what part of your application made the call.

    The Clear button resets all of the data in the dialog.  This can be really useful when you want to get information about one particular scenario.  For example, you may clear the dialog and check in your changes to see what gets called in Visual Studio.

    For those folks who pay really close attention, you may notice that there's a difference in the times that you see in the activity log on the server and the times that you see in the performance dialog.  The difference is due to the fact that the performance dialog is showing you the entire time it took for the client to send the request and start getting the response, whereas the server's activity log shows the time it took for the server to execute the method once it received the request.

    To get this dialog, you'll need to add the following to the .exe.config file for your application.  If you want to see this in Visual Studio for example, you would add this to devenv.exe.config.  The XML snippet goes inside the configuration element.

                <add name="TeamFoundationSoapProxy" value="4" />
                <add name="VersionControl" value="4" />
            <trace autoflush="true" indentsize="3">
                  <add name="perfListener" type="Microsoft.TeamFoundation.Client.PerfTraceListener,Microsoft.TeamFoundation.Client, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

    If you are developing an application and are concerned about performance, this is a valuable tool.

    tags: , ,

  • Buck Hodges

    Getting web sites precompiled with Team Build


    Aaron Hallberg wrote a great post explaining how to build precompiled web sites with Team Build.  The problem is that building them does not, by default, produce precompiled websites where all of the code is in dlls and removed from the ASP.NET source files.

    Team Build and aspnet_compiler.exe


    Because Team Build typically compiles solutions and not projects, an additional complication is introduced with website projects.  By default, these projects have the -u option selected for their compilation in their solution property pages. 

    With this option turned on, aspnet_compiler.exe keeps markup, including inline code, in all *.aspx and *.ashx files (and possibly others - I'm no expert in these matters) so that they can be modified after the site is deployed.  So - if you compile your website projects by using MSBuild to compile the solutions that contain them:

    > msbuild.exe C:\MyProjects\WebApplication.sln

    ...your *.aspx and *.ashx files will be updatable and will not be compiled.  Since Team Build typically compiles solutions, builds done through Team Build will run into the same issue.

    more, including the solution...

    tags: , ,

  • Buck Hodges

    Documentation error results in a build that never ends when building setup projects (.vdproj)


    There's an error in the MSDN documentation on how to build Visual Studio setup projects with Team Build, which several customers have hit now (see this Team Build MSDN forum question).  The result is that the build hangs; it never returns.  The reason is that there's a line break in the MSBuild XML snippet on the MSDN documentation page that results in devenv (VS) being launched as an interactive process rather than with the set of arguments to build a deployment project.  The result is a hang, since nothing can see the instance of VS that's been launched by the build service.

    The documentation page is Walkthrough: Configuring Team Build to Build a Visual Studio Setup Project.

    Here's the XML that contains the error.  In step 6 of the description of the changes needed in the TfsBuild.proj file, there's a line break after "devenv&quot;" that shouldn't be there.

    <Target Name="AfterCompile">
    <Exec Command="&quot;drive letter:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv&quot;
    $(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\HelloWorldTestInstaller.vdproj /Build &quot;Debug|Any CPU&quot;"/>
    <Copy SourceFiles="$(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\Debug\HelloWorldTestInstaller.msi"
    DestinationFolder="$(OutDir)" />
    <Copy SourceFiles="$(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\Debug\setup.exe"
    DestinationFolder="$(OutDir)" />

    Here's the correct version.

    <Target Name="AfterCompile">
    <Exec Command="&quot;drive letter:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv&quot;&quot;$(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\HelloWorldTestInstaller.vdproj /Build &quot;Debug|Any CPU&quot;"/>
    <Copy SourceFiles="$(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\Debug\HelloWorldTestInstaller.msi"
    DestinationFolder="$(OutDir)" />
    <Copy SourceFiles="$(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\Debug\setup.exe"
    DestinationFolder="$(OutDir)" />

    One of the customers that got bitten by this error noticed the incorrect new line and told us about it in email.  After that, we answered a similar post in the forums.  Independently, one of our testers hit the problem last week.  It's funny how these things can pop up seemingly all at once.

    The documentation error should be fixed with the next MSDN documentation update.

    tags: , , ,

  • Buck Hodges

    VC API: CheckIn() may return 0


    Back in March, I wrote a post called How to check in changes on behalf of other users.  Among other things, you'll find the documentation comments for the Workspace.CheckIn() method, which you'll notice is now on MSDN.  While that and How to validate check-in policies, evaluate check-in notes, and check for conflicts are probably the best documentation on how to use CheckIn(), I didn't mention that CheckIn(), which returns the changeset created by checking in, may return 0.

    The version control server automatically undoes the pending changes in the case where you attempt to check in files that haven't changed rather than create new versions of them.  In the extreme case, CheckIn() will return 0 when all of the changes being checked in are edits without content changes or locks.  Nothing bad happened, but the server did not create a changeset.  If something bad happened, such as having one or more conflicts, CheckIn() will throw an exception.

    The CommitCheckinEventArgs object, available by listening to the VersionControlServer object's CommitCheckin event, contains the list of files that were actually checked in (Changes) and the files that were undone (UndoneChanges).

    tags: , , ,

  • Buck Hodges

    Filtering the builds listed in work item tracking


    As soon as folks start using Team Build, especially with some sort of continuous integration support, several issues pop up regarding the integration with work item tracking, including how not to have bad builds listed and how not to have every build from every build type listed.

    When TFS is installed, work item tracking adds a subscription, via bissubscribe.exe, to receive all build completion events.  Builds are listed in the "found in" and "fixed in" fields in work item forms.  Since there is no filtering, every single completed build is added to the list of builds.

    Jason Prickett, a developer working on Team Build, has written a couple of posts that address these issues.  In the first post, he explains the steps needed to change which builds are listed in work item tracking.

    How to filter the Build Completion Event

    One of the fields that ships with the standard Bug Work Item Type in Team Foundation is called “Found In Build”. It allows the user to enter the build number of the build in which they found the bug. It can be found on the Details tab of the Bug work item.

    The “Found In Build” field starts off with the value “<None>” in its drop down list. As Builds are created with Team Foundation Build Automation, the build number is added to this list. This is accomplished by a subscription to the Build Completion Event that was created during installation.

    Unfortunately, the default subscription listens for ALL build completions. In other words, even builds that have compilation errors or fail tests, still make it into the list. This can be a real problem for shops that do frequent builds.


    In the second post, Jason lists the fields that you can use to customize the filter so that you get only the builds you want being listed in work items.

    Useful BuildCompletionEvent filters

    What I didn't give you were the actual filters that you probably need. But first, let's talk about the fields in the event that you can filter. The following list contains the fields and a brief explanation of what they represent.



  • Buck Hodges

    Team Build API: GetBuildUri() and GetBuildDetails()


    Aaron Hallberg plans to periodically post descriptions and examples of some of the more relevant Team Build web service methods.  There's no good source for this information currently.  Even the Team Build API documentation recently published on MSDN won't help you much, as I described here.  If you have particular methods you'd like to know about sooner rather than later, be sure to leave a comment on his blog.

    His first post is about the GetBuildUri() and GetBuildDetails() methods on BuildStore.

    Team Build API: GetBuildUri and GetBuildDetails

    As Buck Hodges recently noted, some Team Build API documentation recently made it up onto MSDN.  Unfortunately, most (maybe all?  I haven't been through it all) of the topics are skeletons, with no real content.  I'll be trying to remedy this by posting fleshed out documentation, sometimes even with examples... 


    tags: , , ,

  • Buck Hodges

    Building web projects with Team Build


    Bernardo Heynemann wrote a nice pair of posts on using Team Build to build and deploy web projects.  While he uses the recently-released continuous integration tool from Notion Solutions (Team CI), there are a number of continuous integration tools for Team Build.

    Team Build 101 (Part 1 of 2)

    Team Build 101 (Part 2 of 2)

    Today we engaged in a task (that seemed daunting at first, but proved to be just a little hard :)) that was the one to setup a team build for Continuous Integration of one of our websites.

    For you guys that didn´t know, MSBuild does not currently support Website deployment out of the box. Well, I didn´t know. And another feature missing is when a check-in occurs start the build (which is the core of Continuous Integration). Lucky bastards as we are, both have already been done. One by Microsoft and the other by Notion Solutions, Inc.

    What we wanted here was:

    1. Launch the Team Build on every check-in.
    2. Get the latest source code in the server.
    3. Build the website solution.
    4. Unit test the website solution.
    5. If everything goes well, zip the built website files and place it in the test site /archived folder with the zip name being: ProjectName_Major_Minor_Build_Release.zip. (this one I borrowed the idea of Douglas Rohm)
    6. If everything goes well copy all the built website files to the test site folder, so the test site always reflect the latest check-ins.
    7. I had to have a way to check the team builds for all our projects without having to look in VS 2005, in two ways:
      1. I wanted to be notified by e-mail.
      2. I wanted RSS Feeds for every team build so I can get notified by RSS Bandit.


    tags: , ,

  • Buck Hodges

    Customizing the new TreeDiff power toy


    If you haven't seen the new TreeDiff, you can see a screen shot in Brian Harry's post about the new release.  It provides a VSS-style project difference tool that allows you not only to see what's changed but also reconcile changes.

    Tan Phan, a developer on the version control client team, has written a post describing how to customize the TreeDiff tool.  He provides a link to Michal Malecki's post about a workaround for the get latest issue as well as how to fix the file extension filtering, change colors, and more.

    tags: , , ,

  • Buck Hodges

    What do you want in the way of power toy checkin policies?


    Mario Rodriguez, a program manager on TFS version control, is seeking your input on what you need in the way of checkin policies for a future power toys release.  An example might be a policy that wraps another policy to provide path filtering to more precisely control what files are subject to a particular checkin policy.

    Please leave a comment on his blog post.

    Check-In Policies Pack Feedback Request

    I have decided to skip the post about merge and deleted items for today in order to get some feedback from you on Check-in Policies. Currently, we are thinking of releasing a check-in policy pack out of band that includes some very commonly used policies, an example being "Check-in comment field cannot be empty".


    tags: , , ,

  • Buck Hodges

    SP1 beta is now available


    For Team Build users, I'll spare you the suspense and tell you that there are no meaningful changes in Team Build itself in SP1.  There are changes in other parts of the system, though, that will be of some benefit.

    Version control users will get a number of fixes, but most are related to scalability.

    Brian Harry described many of the TFS SP1 changes in a post in June.  I'm sure he'll post a follow up soon now that SP1 beta has shipped.

    You can find out how to get the SP1 beta at Microsoft Connect.  Soma's post provides a higher-level description of what's in SP1 beta.

    UPDATE:  Rob Caron has posted the details of what's in SP1 beta.

    tags: , , ,

  • Buck Hodges

    Branching and merging strategies


    I saw Rob Caron mention this new MSDN article, and it's a topic that comes up relatively frequently.  If you've wanted to know more about different strategies for organizing your branches, this article provides a nice overview and links for you to dig deeper.  Another link that may interest you is an article on branching models mentioned in the post, Branching Models.

    Branching and Merging Primer
    Chris Birmele
    Developer Tools Technical Specialist
    Microsoft Pty Ltd, Australia / New Zealand

    August 2006

    Applies to:
    Microsoft Visual Studio 2005 Team Foundation Server

    Summary: An introduction to the concept of software configuration management including information about why configuration management is important, and the various branching and merging strategies. (6 printed pages)

  • Buck Hodges

    How to determine whether tests passed and building a specific version


    Aaron Hallberg has written a couple of posts about Team Build that started with questions from users.  The first deals with how to determine, from code, whether tests passed.

    Determining Whether Tests Passed in Team Build

    In a forum post a while back, I laid out a method for determining whether tests had passed during a build.  More recently, I have linked to this forum post in advising others on similar problems.  Unfortunately, as a sharp user pointed out in this same thread, my solution doesn't actually work, since it relies on a property that is not accessible in Team Build v1!

    So - to remedy the situation I have written a custom task which can be used to determine whether tests have succeeded or not.  This task takes advantage of the GetTestResultsForBuild method of the Microsoft.TeamFoundation.Build.Proxy.BuildStore class.

    The second shows you how to build a specific version.

    Building a Specific Version with Team Build

    Team Build by default gets the latest version of your sources (or tip) from source control.  For the most part, this is probably the behavior you would want and expect.  But not always - you might want to reproduce a particular build that got deleted, for example; or you might want to build your latest changeset without including changes other users might have checked in.

    Unfortunately, getting (and therefore building) a specific version from source control is not supported out of the box in Team Build version 1...

    tags: , , ,

  • Buck Hodges

    Sept. 6th Team System chat transcript is now available


    Brian Keller mentioned that the transcript of the Sept. 6th chat is now available.

    Team System "Chat" transcript now available

    It looks like the the transcript from our September 6th "Chat" on MSDN is now available. It was great meeting everyone who could make it - we had nearly 150 people during the live session which is simply incredible! Team System has become very popular in a relatively short amount of time, which is of course thanks to our customers. So THANK YOU for believing in the product as much as we do!

    For people who couldn't attend the live chat session the transcript is a good way of catching up on common questions related to Team System. There will be another Team System chat on October 4th - get the full chat schedule here: http://msdn.microsoft.com/chats/

    Aaron Hallberg represented Team Build in the chat.  Here are some of the issues that were discussed.  He sent these issues to rest of the team, and they'll be part of the discussion on what goes into future releases.

    • People would like to be able to just have “all tests” in a solution get run, rather than having to specify a VSMDI file.  This is something that various folks have mentioned on the forums as well.
    • One chatter wanted a build machine to be able to communicate with multiple TFS instances. 
    • Brian fielded a question about distributed builds, queuing, etc.
    • We got another question on specifying property value overrides via the GUI when starting a build.
    • There was a question about building MSIs “natively”, rather than having to Exec devenv.exe, use third-party tasks, etc.
    • There was a question about querying for the existing build types, which currently can only be done through the version control OM and not through any build API.

    tags: , ,

  • Buck Hodges

    MSDN chat with the VSTS product team


    Visual Studio Team System Chat
    Come and join members from the the Visual Studio Team System product group to discuss features available in the Visual Studio Architect, Developer and Tester editions as well as Team Foundation Server. There will be experts on hand to answer your questions, so we hope to see you there!

    Add to Calendar

    September 6, 2006
    10:00 - 11:00 A.M. Pacific time
    Additional Time Zones

  • Buck Hodges

    Writing custom loggers for use with Team Build


    If you you're interested in adding a custom logger to your build process in Team Build, Aaron walks you through the steps you need to know.

    Adding Custom Loggers to Team Build

    Yesterday we looked at using tasks to add customized build steps during a build.  Today I'd like to show you how to add a customized logger.

Page 1 of 1 (22 items)