Buck Hodges

Visual Studio Online, Team Foundation Server, MSDN

  • Buck Hodges

    How to diff Word documents


    John Lawrence responded to someone's question about how to diff MS Word documents, and I thought the answer would help a few more folks.

    Team Foundation enables you to specify different diff and merge tools for different file types.

    We don’t have a built in compare tool for .doc files but I did a quick search and found quite a few available for download (e.g. http://www.documentlocator.com/download/difftools.htm). I don’t know if we have any specific recommendations.

    I installed DiffDoc (because it was free… http://www.softinterface.com/MD/MD.htm) and configured it to be my diff tool for .doc files:

    1. Navigate to Tools->Options->Source Control->Visual Studio Team Foundation
    2. Click the Configure User Tools button
    3. In the dialog that pops up, click Add
    4. Enter ‘.doc’ (no apostrophes) in the Extension field to indicate you’re adding a comparison tool for .doc files
    5. For the Command field, click “…” and navigate to your diff tool exe (in my case “C:\Program Files\Softinterface, Inc\DiffDoc\DiffDoc.exe”)
    6. Then enter the command line parameters to drive your specific diff tool. %1 expands to be the original file, %2 expands to the new one. In this case, enter "/M%1 /S%2" in the Arguments text box (without the quotation marks).

    That should do it – next time you try and view a diff of .doc files, it will launch this tool and you should be able to compare them.

  • Buck Hodges

    Team Foundation Beta 3 Virtual PC is available


    The last time I wrote about the VPC for beta 3, it didn't make up to MSDN like it was supposed to.  Well, a beta 3 VPC is available now, and a beta 3 refresh VPC will be available as soon as it makes its way through the infrastructure (yeah, I know, trust me at your own risk).

    The beta 3 VPC is under Visual Studio 2005 -> Visual Studio 2005 Team System Release Candidate -> Visual Studio 2005 Team System Release Candidate VPC (English).  The description is copied below.


    Thank you for evaluating Visual Studio 2005 Team Suite RC and Visual Studio 2005 Team Foundation Server Beta 3. This self-extracting VPC is provided as-is, as governed by the terms of the included EULA.

    VPC Contents

    • Microsoft Windows Server 2003 Standard Edition
    • Microsoft Visual Studio 2005 Team Suite RC
    • Microsoft Visual Studio 2005 Team Foundation Server Beta 3
    • Microsoft .NET Framework 2.0 Redistributable Package RC
    • Microsoft SQL Server 2005 Community Technology Preview
    • Microsoft Office 2003 Standard Edition

    AdventureWorks Demo
    This VPC has been prepared with a sample demo. To access the demo files, open the solution (.sln) file located in the C:\AdventureWorksDemo folder. The sample code is intended to demonstrate features of Visual Studio Team System, and therefore may exhibit poor coding conventions, security vulnerabilites, etc. The AdventureWorks application should not, and may not, be used in any form for production applications.

    Recommended System Requirements

    • PC with 2.0 gigahertz or faster processor
    • 1.5 GB RAM minimum
    • 10 GB available hard disk space
    • Super VGA (800 x 600) or higher video
    • DVD-ROM drive
    • Microsoft Virtual PC 2004 software

    NOTE: For best performance, the VPC should be extracted to a second high-speed hard drive.

  • Buck Hodges

    Hold the shift key and double click


    I wrote this back in August, but these shortcuts weren't availabe in the July CTP.  Now that beta 3 is out, you may want to give them a try.

    I've learned two shortcuts recently that I didn't know existed in TFS source control integration in VS.  These may or may not work based on the build you are using.

    Double clicking the Source Control node in the Team Explorer will bring up the Source Control Explorer window.  What I learned recently is that holding the shift key and double clicking Source Control (after selecting only that node) will bring up the Pending Changes window.

    The other shortcut is more useful.  You may already know that double clicking a file in the checkin window will bring it up in the editor.  If you hold the shift key while double clicking a pending edit, it will launch your diff viewer so you can see what's changed.  That's kind of handy.

  • Buck Hodges

    1,000,000 files in the dogfood system


    Jeff Beehler just checked in another 100,000 files, pushing us over 1,000,000 files.  We now have 1,042,659 files in the dogfood system.  Brian Harry sent out a dogfood statistics update in email today, prior to Jeff's check-in.  Watch for the latest stats on John Lawrence's blog.

  • Buck Hodges

    Go to Changeset coming for RTM


    You still won't be able to drag and drop in Source Control Explorer (some changes are just too large at this point), but you will be able to go to a changeset (without going through the back door using Get Specific Version solely for changeset look up).  In the next drop, the Edit -> Go to menu item will bring up the Find Changeset dialog when the Source Control Explorer has focus.  Also, it should appear on the Team menu.

    How about a power toy VS plugin to fill in the gaps?

    There are lots of things we'd like to do, but we can't at this point in the cycle.  We are thinking about putting together a VS power toy plugin with some of the things that didn't make it into v1, for version control and work item tracking.  What power toy features would help you get more done and have a happier v1 experience?

  • Buck Hodges

    How to work around the diff viewer problem in Team Explorer Beta 3


    If you install only the Team Explorer (and not VSTS), there is a known issue (7.3) where the diff viewer won't work.  It also affects the built-in merge tool, but I think that's less painful for users who just need Team Explorer.

    The tool is diffmerge.exe, and it uses msdiff.dll. The msdiff.dll needs several missing several VC runtime dlls that normally get installed as part of the VS installation.

    To work around this problem in beta 3, you can hook up a third-party diff tool.  Just go to Tools->Options->Source Control->Visual Studio Team Foundation Server and click on Configure User Tools to specify the diff tool of your choice.  Enter "*" for the Extension, the path to your diff viewer's executable in the Command and leave the Arguments as "%1 %2" to hook it up.

    For example, you could use windiff from the Windows XP tools.  I think you can just copy the windiff.exe after extracting it on one machine.

    You can find some docs for it here.

  • Buck Hodges

    How to upgrade from TFS Beta 3 to RTM


    Allen Clark has posted the document on upgrading beta 3 to RTM so you'll know what to expect.

    Preparing to upgrade to RTM

    If you’re using Beta 3 Refresh, you may be wondering what you can do now to make the server upgrade to RTM as painless as possible. Here are a few things that will help.

    • If you customize work item types, don’t create work item field reference names that have more than 70 characters, or that begin with a number.
    • If it’s not too late, deploy Team Foundation Server on the hardware you’re going to use at RTM.
    • If you are going to deploy to new hardware, go ahead and install Team Foundation Server on the new hardware and try it out just to make sure you don't have configuration issues. You can uninstall Team Foundation prior to upgrading.
    • Keep track of the customizations you’re making to the process templates; you’ll need to do these again before you’ll be able to create new projects with your custom process templates.

    I’ve included the specification below so that you can get a better idea of what the upgrade will be like and let us know if you feel like we haven’t covered your scenario. Keep in mind that this isn’t final, but the actual upgrade will be similar to what’s described here.

    Allen Clark

    Program Manager, Team Foundation Server

    Design Goals

    When V1 ships, customers must be able to upgrade their data without support from Microsoft.

    • Upgrading to RTM will not be effortless, but the work required must be reasonable.
    • Customers should not get into a server-down state unexpectedly.
    • Minimize the impact on the Setup team.
  • Buck Hodges

    Power Toy: tfpt.exe


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

    [UPDATE 9/8/2006]  TFPT is now available in its own small download: http://go.microsoft.com/?linkid=5422499!  You no longer need to download the VS SDK.  You can find more information about the September '06 release here.

    Back at the start of October, I wrote about the tfpt.exe power toy.  The beta 3 version has been released with the October SDK release.  In the future, we plan to have a better vehicle for delivering it.

    Here's the documentation, minus the screenshots, in case you are trying to decide whether to download the SDK.  The documentation is included in the SDK release as a Word document, including screenshots of the various dialogs (yes, most commands have a GUI, but you can still use the commands from scripts by specifying the /noprompt option).

    Review  The only command not documented is the review command, which is very handy for doing code reviews.  When you run "tfpt review" you get a dialog with a list of your pending changes that you can check off as you diff or view each one.

    I hope you find these useful.  Please leave a comment, and let us know what you think.

    Team Foundation PowerToys


    The Team Foundation PowerToys (TFPT) application provides extra functionality for use with the Team Foundation version control system. The Team Foundation PowerToys application is not supported by Microsoft.

    Five separate operations are supported by the TFPT application: unshelve, rollback, online, getcs, and uu. They are all invoked at the command line using the tfpt.exe application. Some of the TFPT commands have graphical interfaces.

    Unshelve (Unshelve + Merge)

    The unshelve operation supported by tf.exe does not allow shelved changes and local changes to be merged together. TFPT’s more advanced unshelve operation allows this to occur under certain circumstances.

    If an item in the local workspace has a pending change that is an edit, and the user uses TFPT to unshelve a change from a shelveset, and that shelved change is also an edit, then the changes can be merged with a three-way merge.

    In all other cases where changes exist both in the local workspace and in the shelveset, the user can choose between the local and shelved changes, but no combination of the changes can be made. To invoke the TFPT unshelve tool, execute

    tfpt unshelve

    at the command line. This will invoke the graphical interface for the TFPT unshelve tool:

    Running TFPT Unshelve on a Specified Shelveset

    To skip this dialog, you can specify the shelveset name and owner on the command line, with

    tfpt unshelve shelvesetname;shelvesetowner

    If you are the owner of the shelveset, then specifying the shelveset owner is optional.

    Selecting Individual Items Within a Shelveset for Unshelving

    If you specify a shelveset on the command line as in “Running TFPT Unshelve on a Specified Shelveset,” or if you select a shelveset in the window above and click Details, you are presented with the Shelveset Details window, where you can select individual changes within a shelveset to unshelve.

    You can check and uncheck the boxes beside individual items to mark or unmark them for unshelving. Click the Unshelve button to proceed.

    Unshelve Conflicts

    When you press the Unshelve button, all changes in the shelveset for which there is no conflicting local change will be unshelved. You can see the status of this unshelve process in the Command Prompt window from which you started the TFPT unshelve tool.

    There may, however, be conflicts which must be resolved for the unshelve to proceed. If any conflicts are encountered, the conflicts window is displayed:

    Edit-Edit Conflicts

    To resolve an edit-edit conflict, select the conflict in the list view and click the Resolve button. The Resolve Unshelve Conflict window appears.

    For edit-edit conflicts, there are three possible conflict resolutions. 

    • Taking the local change abandons the unshelve operation for this particular change (it would be as if the change had not been selected for unshelving).
    • Taking the shelved change first undoes the local change, and then unshelves the shelved change. This results in the local change being completely lost.
    • Clicking the Merge button first attempts to auto-merge the two changes together, and if it cannot do so without conflict, attempts to invoke a pre-configured third-party merge tool to merge the changes together. The local change is not lost by choosing to merge – if the merge fails, the local change remains.

    The Auto-Merge All Button

    The Auto-Merge All button is enabled when there are edit-edit conflicts remaining that are unresolved. Clicking the button goes through the edit-edit conflicts and attempts to auto-merge the changes together. For each conflict, if the merge succeeds, then the conflict is resolved. If not, then the conflict is marked as “Requires Manual Merge.” In order to resolve conflicts marked as “Requires Manual Merge,” you must select the conflict and click the Resolve… button. Clicking the Merge button will then start the configured third-party merge tool. If no third-party merge tool is configured, then the conflict must be resolved by selecting to take the local change or take the shelved change.

    Generic Conflicts

    Any other conflict (a local delete with a shelved edit, for example) is a generic conflict that cannot be merged.

    There is no merge option for generic conflicts. You must choose between keeping the local change and taking the shelved change.

    Aborting the Unshelve Process

    Because the unshelving process makes changes to the local workspace, and because the potential exists to discover a problem halfway through the unshelve process, the TFPT Unshelve application makes a backup of the local workspace before starting its execution if there are pending local changes. This backup is stored as a shelveset on the server. In the event of an abort, all local pending changes are undone and the backup shelveset is unshelved to the local workspace. This restores the workspace to the state it was in before the unshelve application was run.

    The backup shelveset is named by adding _backup and then a number to the name of the shelveset that was unshelved. For example, if the shelveset TestSet were unshelved, the backup shelveset would be named TestSet_backup1. Up to 9 backup shelvesets can exist for each shelveset.

    With the backup shelveset, changes made during an unshelve operation can be undone after the unshelve is completed but before the changes are checked in, by undoing all changes in the workspace and then unshelving the backup shelveset:

    tf undo * /r

    tf unshelve TestSet_backup1


    Sometimes it may be necessary to undo a checkin of a changeset. This operation is directly not supported by Team Foundation, but with the TFPT rollback tool you can pend changes which attempt to undo any changes made in a specified changeset.

    Not all changes can be rolled back, but in most scenarios the TFPT rollback command works. In any event, the user is able to review the changes that TFPT pends before checking them in.

    To invoke the TFPT rollback tool, execute

    tfpt rollback

    at the command line. This will invoke the graphical user interface (GUI) for the TFPT rollback tool. Please note that there must not be any changes in the local workspace for the rollback tool to run. Additionally, a prompt will be displayed to request permission to execute a get operation to bring the local workspace up to the latest version.

    The Find Changesets window is presented when the TFPT rollback tool is started. The changeset to be rolled back can be selected from the Find Changesets window.

    Specifying the Changeset on the Command Line

    The Find Changesets window can be skipped by supplying the /changeset:changesetnum command line parameter, as in the following example:

    tfpt rollback /changeset:3

    Once the changeset is selected, either by using the Find Changesets window or specifying a changeset using a command-line parameter, the Roll Back Changeset window is displayed.

    Each change is listed with the type of change that will be counteracted by a rollback change.

    To rollback a:

    The tool pends a:

    Add, Undelete, or Branch








    Unchecking a change in the Roll Back Changeset window marks it as a change not to be rolled back. There are cases involving rolling back deletes which may result in unchecked items being rolled back. If this occurs, clear warnings to indicate this are displayed in the command prompt window. If this is unsatisfactory, undo the changes pended by the rollback tool.

    When the changes to roll back have been checked appropriately, pressing the Roll Back button starts the rollback. If no failures or merge situations are encountered, then the changes should be pended and the user returned to the command prompt:

    Merge scenarios can arise when a rollback is attempted on a particular edit change to an item that occurred in-between two other edit changes. There are two possible edit rollback scenarios: 

    1. An edit is being rolled back on an item, and the edit to roll back is the latest change to the content of the item. 

    This is the most common case. Most rollbacks are performed on changesets that were just checked in. If the edit was just checked in, it is unlikely that another user has edited it in the intervening time.

    To roll back this change, an edit is pended on the item, and the content of the item is reverted to the content from before the changeset to roll back. 

    1. An edit is being rolled back on an item, and the edit to roll back is not the latest change to the content of the item. 

    This is a three-way merge scenario, with the version to roll back as the base, and the latest version and the previous version as branches. If there are no conflicts, then the changes from the change to roll back (and only the change to roll back) are extracted from the item, preserving the changes that came after the change to roll back. 

    In the event of a merge scenario, the merge window is displayed:

    To resolve a merge scenario, select the item and click the Merge button. An auto-merge will first be attempted, and if it fails, the third-party merge tool (if configured) will be invoked to resolve the merge. If no third-party merge tool is configured, and the auto-merge fails, then the item cannot be rolled back:

    The Auto-Merge All button attempts an auto-merge on each of the items in the merge list, but does not attempt to invoke the third-party merge tool.


    Any changes which fail to roll back will also be displayed in the same window.


    With Team Foundation, a server connection is necessary to check files in or out, to delete files, to rename files, etc. The TFPT online tool makes it easier to work without a server connection for a period of time by providing functionality that informs the server about changes made in the local workspace.

    Non-checked-out files in the local workspace are by default read-only. The user is expected to check out the file with the tf checkout command before editing the file. When working in this

    When working offline with the intent to sync up later by using the TFPT online tool, users must adhere to a strict workflow: 

    • Users without a server connection manually remove the read-only flag from files they want to edit. Non-checked-out files in the local workspace are by default read-only, and when a server connection is available the user must check out the file with the tf checkout command before editing the file. When working offline, the DOS command “attrib –r” should be used.
    • Users without a server connection add and delete files they want to add and delete. If not checked out, files selected for deletion will be read-only and must be marked as writable with “attrib –r” before deleting. Files which are added are new and will not be read-only.
    • Users must not rename files while offline, as the TFPT online tool cannot distinguish a rename from a deletion at the old name paired with an add at the new name.
    • When connectivity is re-acquired, users run the TFPT online tool, which scans the directory structure and detects which files have been added, edited, and deleted. The TFPT online tool pends changes on these files to inform the server what has happened.  

    To invoke the TFPT online tool, execute 

    tfpt online

    at the command line. The online tool will begin to scan your workspace for writable files and will determine what changes should be pended on the server.

    By default, the TFPT online tool does not detect deleted files in your local workspace, because to detect deleted files the tool must transfer significantly more data from the server. To enable the detection of deleted files, pass the /deletes command line option.

    When the online tool has determined what changes to pend, the Online window is displayed.

    Individual changes may be deselected here if they are not desired. When the Pend Changes button is pressed, the changes are actually pended in the workspace.

    Important Note: If a file is edited while offline (by marking the file writable and editing it), and the TFPT online tool pends an edit change on it, a subsequent undo will result in the changes to the file being lost. It is therefore not a good idea to try pending a set of changes to go online, decide to discard them (by doing an undo), and then try again, as the changes will be lost in the undo. Instead, make liberal use of the /preview command line option (see below), and pend changes only once.

    Preview Mode

    The Online window displayed above is a graphical preview of the changes that will be pended to bring the workspace online, but a command-line version of this functionality is also available. By passing the /preview and /noprompt options on the command line, a textual representation of the changes that the TFPT online tool thinks should be pended can be displayed.

    tfpt online /noprompt /preview


    The TFPT online tool by default operates on every file in the workspace. Its focus can be more directed (and its speed improved) by including only certain files and folders in the set of items to inspect for changes. Filespecs (such as *.c, or folder/subfolder) may be passed on the command line to limit the scope of the operation, as in the following example:

    tfpt online *.c folder\subfolder

    This command instructs the online tool to process all files with the .c extension in the current folder, as well as all files in the folder\subfolder folder. No recursion is specified. With the /r (or /recursive) option, all files matching *.c in the current folder and below, as well as all files in the folder\subfolder folder and below will be checked. To process only the current folder and below, use

    tfpt online . /r


    Many build systems create log files and/or object files in the same directory as source code which is checked in. It may become necessary to filter out these files to prevent changes from being pended on them. This can be achieved through the /exclude:filespec1,filespec2,… option.

    With the /exclude option, certain filemasks may be filtered out, and any directory name specified will not be entered by the TFPT online tool. For example, there may be a need to filter out log files and any files in object directories named “obj”.

    tfpt online /exclude:*.log,obj

    This will skip any file matching *.log, and any file or directory named obj.

    GetCS (Get Changeset)

    The TFPT GetCS tool gets all the items listed in a changeset at that changeset version.

    This is useful in the event that a coworker has checked in a change which you need to have in your workspace, but you cannot bring your entire workspace up to the latest version. You can use the TFPT GetCS tool to get just the items affected by his changeset, without having to inspect the changeset, determine the files listed in it, and manually list those files to a tf.exe get command.

    There is no graphical user interface (GUI) for the TFPT GetCS tool. To invoke the TFPT GetCS tool, execute

    tfpt getcs /changeset:changesetnum

    at the command line, where changesetnum is the number of the changeset to get.

    UU (Undo Unchanged)

    The TFPT UU tool removes pending edits from files which have not actually been edited.

    This is useful in the event that you check out fifteen files for edit, but only actually make changes to three of them. You can back out your edits on the other twelve files by running the TFPT UU tool, which compares hashes of the files in the local workspace to hashes the server has to determine whether or not the file has actually been edited.

    There is no graphical user interface (GUI) for the TFPT UU tool. To invoke the TFPT UU tool, execute

    tfpt uu

    at the command line. You can also pass the /changeset:changesetnum argument to compare the files in the workspace to a different version.


    Help for each TFPT tool, as well as all its command-line switches, is available at the command line by running

    tfpt help

    or for a particular command, with

    tfpt help <command>


    tfpt <command> /?

  • Buck Hodges

    Brian Harry on when to ship TFS

    About half way through a thread on unlocking files locked by another user, Brian wrote a long response in the Team Foundation Forum about deciding what changes to make at this point and knowing when to ship.  It's a good read.  I expect that Brian will likely turn it into a blog post at some point.
  • Buck Hodges

    Validating XML characters in SOAP messages


    I've written about using the SoapHttpClientProtocol subclasses generated by wsdl.exe several times over the last year, including handling authentication, HTTP response codes, and setting timeouts properly.  Today I needed to change the code in TFS to better handle characters that are not allowed in XML.

    The problem is that if you have a method on your web service that takes a String parameter, someone may call that method with a string that contains characters that are not allowed in XML.  That input may come from a command line switch or a text box in a GUI.

    The XmlWriter used by SoapHttpClientProtocol is XmlTextWriter.  XmlTextWriter doesn't do any character validation.  If the string passed to WriteString() includes characters that are not valid for XML, your XML output will also.  The characters below 32, except for tab, carriage return, and new line, the UTF-8 BOM, and invalid surrogate pairs are not allowed by the XML standard.

    The XmlReader used by the ASP.NET web services does do character validation.  If it finds an invalid XML character, the web service will respond with HTTP 400 Bad Request.  That doesn't help the user figure out what's going on.

    Elena Kharitidi suggested overriding the GetWriterForMessage() method from SoapHttpClientProtocol in the subclass that was generated by wsdl.exe and providing a character-validating XmlWriter.

    The documentation shows an example of creating a subclass of XmlTextWriter to check the characters.  However, it would be better to be able to use a framework class to do it without rolling our own.  Fortunately, there is such a class in the framework.

    With a little poking around, I found the XmlCharCheckingWriter class that is internal to the framework.  Now we just need to get the framework to give us an instance of that class.  A little more poking around and experimentation resulted in the piece of code shown below.

    If you run it under the debugger and put a breakpoint on line 5, you'll see that the base SoapHttpClientProtocol method returns an XmlTextWriter.  If you step down to the XmlWriter.Create() call, you'll see that the framework gives us the XmlCharCheckingWriter instance that we want in response to the CheckCharacters setting being true.

    Now, if you add the following code to your wsdl.exe-generated subclass of SoapHttpClientProtocol, you'll get an ArgumentException on the client when trying to write the invalid XML in the SOAP message.  The exception message will state that there is an invalid character.  The result is a significant improvement over getting a generic HTTP 400 Bad Request from the web service.

    // Override this method in order to put in character validation.
    protected override XmlWriter GetWriterForMessage(SoapClientMessage message,
                                                     int bufferSize)
        XmlWriter writer = base.GetWriterForMessage(message, bufferSize);
        // Choose the encoding the same way the framework code does.
        Encoding encoding = RequestEncoding != null ? RequestEncoding :
                                                      new UTF8Encoding(false);
        // We want the character validation to be done on the client side
        // rather than getting an obscure HTTP 400 Bad Request message
        // from the server (the XmlReader used by the web services does 
        // character validation, while the writer used in the base class
        // does not).
        // We create this second XmlWriter to get an XmlCharCheckingWriter
        // instance.  The Create(XmlWriter, XmlWriterSettings) code path 
        // does that (we don't need the overhead in an XmlWellformedWriter).
        XmlWriterSettings xws = new XmlWriterSettings();
        xws.Encoding = encoding;
        xws.Indent = false;
        xws.NewLineHandling = NewLineHandling.None;
        xws.CheckCharacters = true;      // make sure char is valid for XML
        writer = XmlWriter.Create(writer, xws);
        return writer;
  • Buck Hodges

    Getting email when someone overrides a policy


    James Manning today pointed out a post from Marcel de Vries showing how to register for email when someone checks in after overriding a policy failure.  While any policy failres and override comment are included in the standard check-in email, this allows you to get an email specifically when someone overrides a policy failure.  It's only a few lines of code, and it uses the built-in event system support for sending emails.  He even provides a link to a zip file with the solution.

    How to receive email on a Team Foundation check in policy violation

    [Update] He mentions in the post that the delivery of the events is guaranteed: "the implementation also has a guaranteed delivery system using SQL server."  Though the events do get queued for delivery in a table in the SQL DB, there's no guarantee that an event gets recorded, because the recoding of the event is not transactional with respect to the work that generated the event.  It's pretty robust, but it's not guaranteed.

  • Buck Hodges

    Beta 3 refresh released


    Beta 3 of TFS has now been released and should be available on MSDN today (or very soon :-).  The differences between beta 3 and beta 3 refresh are small for most things.  Jeff Beehler wrote about some of the beta 3 refresh differences two weeks ago.  The most important reason for the beta 3 refresh is that it is built against and uses all of the final release versions of Visual Studio 2005, .NET 2.0, and SQL Server 2005.  Beyond that, many of the fixes in it were to enhance the setup experience and to address a few localization issues.  So, if you are wondering whether some particular bug is fixed, the answer is most likely to be no, with the exception of some issues that Jeff mentioned.

    If you have beta 3 installed, you'll want to read the following guide to succesfully upgrade without losing your existing data.

    Migrating to Visual Studio 2005 Team Foundation Server Beta 3 Refresh

  • Buck Hodges

    Changing the encoding of a pending add works for RTM

    I had mentioned in my September 10th post on file type detection that you couldn't change the encoding on a pending add, without undoing the add and re-adding it.  While it won't work in beta 3 or beta 3 refresh, you'll be able to change the encoding on a pending add in the next public release.  That means you can use the edit command with /type option from the command line or the properties dialog in the GUI to tweak the encoding before checking it in.
  • Buck Hodges

    Displaying the sizes and dates of files in the server


    Have you wished that the output of the dir command from tf.exe would show you the dates and sizes of the files like cmd.exe's dir command?  Even though tf.exe won't do that in version 1, the version control API provides the call necessary.  This little app is similar to my last post on displaying labels on a file.  You can find a simple example of creating a workspace, pending changes, and so forth in my September API example.

    The GetItems() method is the key part of the app.  Here's the declaration on the VersionControlServer class.

    public ItemSet GetItems(String path, RecursionType recursion)

    For this overload of the GetItems() method, there's no version parameter, so it defaults to get the Item objects for the latest version in the repository.  There is another overload that takes the version, and you could pass "new WorkspaceVersionSpec(wsInfo.Name, wsInfo.OwnerName)" as the version to get the Item objects corresponding to the versions in the workspace.

    The first argument is the path on which we want data.  That can be either a local path or a server path.

    The recursion parameter specifies how deep we want to go.  If the path is a directory, specifying RecursionType.OneLevel retrieves only the items directly contained in that directory, just like specifying the wildcard "*" would.  If the path is a file, there is no difference between one level of recursion and none because a file can't have children.  The default for this app is onle level of recursion, which is the same as what both cmd.exe's dir command and tf.exe's dir command use.

    If the user specifies /r, the app passes RecursionType.Full.  For a directory, that will return all of its descendants.  If the path doesn't match a directory, the server will recursively find all items under path that match.  The path it uses is the directory portion of the path, and the pattern is the file name portion of the path.  So, if the user specifies "c:\project\readme.txt /r" the server will return all files called readme.txt underneath c:\project, recursively.

    In the app, we only want the items for display, which is the Items property on the ItemSet object returned by GetItems().  The other two properties on ItemSet, QueryPath and Pattern, indicate how the server used the specified path to do the matching.  In our previous example of "c:\project\readme.txt /r" the result would be QueryPath set to the server path corresponding to c:\project and Pattern set to readme.txt.

    Here's an example of running the app.

    D:\ws1>D:\code\projects\DirSize\DirSize\bin\Debug\DirSize.exe . /r
    10/25/2005 11:40:25 AM    <DIR>             $/testproj
    10/25/2005 03:59:50 PM    <DIR>             $/testproj/A
    10/25/2005 03:59:50 PM    <DIR>             $/testproj/B
    10/26/2005 11:04:34 PM                 7996 $/testproj/out.txt
    10/25/2005 04:55:50 PM                    6 $/testproj/A/a.txt

    2 files, 3 folders, 8002 bytes

    To build it, you can create a Windows console app in Visual Studio, drop this code into it, and add the following references to the VS project.


    using System;
    using System.Globalization;
    using System.IO;
    using Microsoft.TeamFoundation;
    using Microsoft.TeamFoundation.Client;
    using Microsoft.TeamFoundation.VersionControl.Client;
    using Microsoft.TeamFoundation.VersionControl.Common;
    namespace DirSize
        class Program
            static void Main(string[] args)
                // Check and get the arguments.
                String path;
                RecursionType recursion;
                VersionControlServer sourceControl;
                GetPathAndRecursion(args, out path, out recursion, out sourceControl);
                Item[] items = null;
                    // Get the latest version of the information for the items.
                    ItemSet itemSet = sourceControl.GetItems(path, recursion);
                    items = itemSet.Items;
                catch (TeamFoundationServerException e)
                    // We couldn't contact the server, the item wasn't found,
                    // or there was some other problem reported by the server,
                    // so we stop here.
                if (items.Length == 0)
                    Console.WriteLine("There are no items for " + path);
                    Array.Sort(items, Item.Comparer);
                    long totalBytes = 0;
                    int numFiles = 0, numFolders = 0;
                    String format = "{0,-25} {1,-8} {2, 8} {3}";
                    foreach (Item item in items)
                        if (item.ItemType == ItemType.File)
    // In addition to the information printed, the Item object has
    // the changeset version and MD5 hash of the file content as
    // properties on item
    . numFiles++; totalBytes += item.ContentLength; Console.WriteLine(format, item.CheckinDate.ToLocalTime().ToString("G"), String.Empty, item.ContentLength, item.ServerItem); } else { numFolders++; Console.WriteLine(format, item.CheckinDate.ToLocalTime().ToString("G"), "<DIR>", String.Empty, item.ServerItem); } } Console.WriteLine(); Console.WriteLine("{0} files, {1} folders, {2} bytes", numFiles, numFolders, totalBytes); } } private static void GetPathAndRecursion(String[] args, out String path, out RecursionType recursion, out VersionControlServer sourceControl) { if (args.Length > 2 || args.Length == 1 && args[0] == "/?") { Console.WriteLine("Usage: dirsize"); Console.WriteLine(" dirsize [path] [/r]"); Console.WriteLine(); Console.WriteLine("With no arguments, shows the size information for the current directory."); Console.WriteLine("If a path is specified, it shows the size information for that path."); Console.WriteLine("If /r is specified, all of the children of the path will be included."); Console.WriteLine(); Console.WriteLine("Examples: dirsize $/secret"); Environment.Exit(1); } // Figure out the server based on either the argument or the // current directory. WorkspaceInfo wsInfo = null; if (args.Length < 1 || args.Length == 1 && args[0] == "/r") { path = Environment.CurrentDirectory; } else { path = args[0]; try { if (!VersionControlPath.IsServerItem(path)) { wsInfo = Workstation.Current.GetLocalWorkspaceInfo(path); } } catch (Exception e) { // The user provided a bad path argument. Console.Error.WriteLine(e.Message); Environment.Exit(1); } } if (wsInfo == null) { wsInfo = Workstation.Current.GetLocalWorkspaceInfo(Environment.CurrentDirectory); } // Stop if we couldn't figure out the server. if (wsInfo == null) { Console.Error.WriteLine("Unable to determine the server."); Environment.Exit(1); } TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(wsInfo.ServerName); // RTM: wsInfo.ServerUri.AbsoluteUri); sourceControl = (VersionControlServer)tfs.GetService(typeof(VersionControlServer)); // Pick up the recursion, if supplied. By default, // we want item and its immediate children, if it is a folder. // If the item is a file, then only the file will be returned. recursion = RecursionType.OneLevel; if (args.Length == 1 && args[0] == "/r" || args.Length == 2 && args[1] == "/r") { recursion = RecursionType.Full; } } } }

    [Update 11/4/2005] I added some explanation of the version used with the GetItems() call and the HashValue property of the Item class.
  • Buck Hodges

    Displaying the labels on a file, including label comments


    Unfortunately, there's not a fast, efficient way to see the list of labels in the system with the full comment without also seeing a list of all of the files included in a label.  You also can't efficiently answer the question, "What labels involve foo.cs?"  While this won't be changed for v1, you can certainly do it using code.  I mentioned on the TFS forum that I'd try to put together a piece of code to do this.  The result is the code below.

    The code is really simple to do this, but I ended up adding more to it than I originally intended.  All that's really necessary here is to call QueryLabels() to get the information we need.

    Let's look at the QueryLabels() call in a little detail, since it is the heart of the app.  Here is the method declaration from the VersionControlServer class.

    public VersionControlLabel[] QueryLabels(String labelName,
    String labelScope,
                                             String owner, 
                                             bool includeItems,
                                             String filterItem,
                                             VersionSpec versionFilterItem)

    By convention, methods that begin with "Query" in the source control API allow you to pass null to mean "give me everything."  In the code below, I don't want to filter by labelName or owner, so I set those to null to include everything.

    If the user specified a server path for the scope (scope is always a server path and not a local path), we'll use it, and otherwise we'll use the root ($/).  The scope of a label is, effectively, the part of the tree where it has ownership of that label name.  In other words by specifying the label scope, $/A and $/B can have separate labels named Foo, but no new label Foo can be used under $/A or $/B.  For this program, setting the scope simply narrows the part of the tree it will include in the output.  For example, running this with a scope of $/A would show only one label called Foo, but running it with $/ as the scope (or omitting the scope) would result in two Foo labels being printed.

    Folder PATH listing for volume Dev
    Volume serial number is 0006EE50 185C:793F

    D:\ws1>tf label Foo@$/testproj/A A
    Created label

    D:\ws1>tf label Foo@$/testproj/B B
    Created label

    Foo (10/25/2005 4:00 PM)
    Foo (10/25/2005 4:00 PM)

    The most important parameter here is actually includeItems.  By setting this parameter to false, we'll get the label metadata without getting the list of files and folders that are in the label.  This saves both a ton of bandwidth as well as load on the server for any query involving real-world labels that include many thousands of files.

    The remaining parameters are filterItem and versionFilterItem.  The filterItem parameter allows you to specify a server or local path whereby the query results will only include labels involving that file or folder.  It allows you to answer the question, "What labels have been applied to file foo.cs?"  The versionFilterItem is used to specify what version of the item had the specified path.  It's an unfortunate complexity that's due to the fact that we support rename (e.g., A was called Z at changeset 12, F at changeset 45, and A at changeset 100 and beyond).  Before your eyes glaze over (they haven't already, right?), I just set that parameter to latest.

    Here's an example of using the program with the tree mentioned earlier.  I modified the Foo label on A to have a comment, so it has a later modification time.

    D:\ws1>tf label Foo@$/testproj/A /comment:"This is the first label I created."
    Updated label Foo@$/testproj/A

    Foo (10/25/2005 4:05 PM)
       Comment: This is the first label I created.
    Foo (10/25/2005 4:00 PM)

    Then I added a file under A, called a.txt, and modified the label to include it.  Running the app on A\a.txt, we see that it is only involved in one of the two labels in the system.

    D:\ws1>tf label Foo@$/testproj/A A\a.txt
    Updated label

    D:\ws1>d:\LabelHistory\LabelHistory\bin\Debug\LabelHistory.exe A\a.txt
    Foo (10/25/2005 4:56 PM)
       Comment: This is the first label I created.

    To build it, you can create a Windows console app in Visual Studio, drop this code into it, and add the following references to the VS project.


    using System;
    using System.IO;
    using Microsoft.TeamFoundation;
    using Microsoft.TeamFoundation.Client;
    using Microsoft.TeamFoundation.VersionControl.Client;
    using Microsoft.TeamFoundation.VersionControl.Common;
    namespace LabelHistory
        class Program
            static void Main(string[] args)
                // Check and get the arguments.
                String path, scope;
                VersionControlServer sourceControl;
                GetPathAndScope(args, out path, out scope, out sourceControl);
                // Retrieve and print the label history for the file.
                VersionControlLabel[] labels = null;
                    // The first three arguments here are null because we do not
                    // want to filter by label name, scope, or owner.
                    // Since we don't need the server to send back the items in
                    // the label, we get much better performance by ommitting
                    // those through setting the fourth parameter to false.
                    labels = sourceControl.QueryLabels(null, scope, null, false, 
                                                       path, VersionSpec.Latest);
                catch (TeamFoundationServerException e)
                    // We couldn't contact the server, the item wasn't found,
                    // or there was some other problem reported by the server,
                    // so we stop here.
                if (labels.Length == 0)
                    Console.WriteLine("There are no labels for " + path);
                    foreach (VersionControlLabel label in labels)
                        // Display the label's name and when it was last modified.
                        Console.WriteLine("{0} ({1})", label.Name,
                        // For labels that actually have comments, display it.
                        if (label.Comment.Length > 0)
                            Console.WriteLine("   Comment: " + label.Comment);
            private static void GetPathAndScope(String[] args,
                                                out String path, out String scope,
                                                out VersionControlServer sourceControl)
                // This little app takes either no args or a file path and optionally a scope.
                if (args.Length > 2 || 
                    args.Length == 1 && args[0] == "/?")
                    Console.WriteLine("Usage: labelhist");
                    Console.WriteLine("       labelhist path [label scope]");
                    Console.WriteLine("With no arguments, all label names and comments are displayed.");
                    Console.WriteLine("If a path is specified, only the labels containing that path");
                    Console.WriteLine("are displayed.");
                    Console.WriteLine("If a scope is supplied, only labels at or below that scope will");
                    Console.WriteLine("will be displayed.");
                    Console.WriteLine("Examples: labelhist c:\\projects\\secret\\notes.txt");
                    Console.WriteLine("          labelhist $/secret/notes.txt");
                    Console.WriteLine("          labelhist c:\\projects\\secret\\notes.txt $/secret");
                // Figure out the server based on either the argument or the
                // current directory.
                WorkspaceInfo wsInfo = null;
                if (args.Length < 1)
                    path = null;
                    path = args[0];
                        if (!VersionControlPath.IsServerItem(path))
                            wsInfo = Workstation.Current.GetLocalWorkspaceInfo(path);
                    catch (Exception e)
                        // The user provided a bad path argument.
                if (wsInfo == null)
                    wsInfo = Workstation.Current.GetLocalWorkspaceInfo(Environment.CurrentDirectory);
                // Stop if we couldn't figure out the server.
                if (wsInfo == null)
                    Console.Error.WriteLine("Unable to determine the server.");
                TeamFoundationServer tfs =
                                                          // RTM: wsInfo.ServerUri.AbsoluteUri);
                sourceControl = (VersionControlServer)tfs.GetService(typeof(VersionControlServer));
                // Pick up the label scope, if supplied.
                scope = VersionControlPath.RootFolder;
                if (args.Length == 2)
                    // The scope must be a server path, so we convert it here if
                    // the user specified a local path.
                    if (!VersionControlPath.IsServerItem(args[1]))
                        Workspace workspace = wsInfo.GetWorkspace(tfs);
                        scope = workspace.GetServerItemForLocalItem(args[1]);
                        scope = args[1];

    [Update 10/26] I added Microsoft.TeamFoundation.Common to the list of assemblies to reference.

    [Update 7/12/06]  Jeff Atwood posted a VS solution containing this code and a binary.  You can find it at the end of http://blogs.vertigosoftware.com/teamsystem/archive/2006/07/07/Listing_all_Labels_attached_to_a_file_or_folder.aspx.

  • Buck Hodges

    Web Load Testing webcast Tuesday (Oct. 25) at 1:00 pm PST


    If you want to learn more about web load testing in VSTS, you'll want to check out Ed Glas' webcast on Tuesday, Oct. 25.  Brian Harry has been using VSTS load testing developed by Ed's group to answer the question, "How many users will your Team Foundation Server support?"  Find out how you can do the same for your own web site or web service.

    MSDN Webcast: Load and Web Testing with Microsoft Visual Studio 2005 Team System (Level 200)    

    Start Time:   Tuesday, October 25, 2005 1:00 PM (GMT-08:00) Pacific Time (US & Canada) 
    End Time:
       Tuesday, October 25, 2005 2:00 PM (GMT-08:00) Pacific Time (US & Canada) 
    Event Description 
     Products: Visual Studio.

     Recommended Audience: Developer.

     Language: English-American
     Description:   By using Microsoft Visual Studio 2005 Team System as a platform, you can better manage the software development life cycle. You have the flexibility to customize and extend this platform to meet organizational needs. In this webcast, gain a general understanding of the Web and load testing features in Visual Studio 2005.

    Presenter: Ed Glas, Group Manager, Microsoft Corporation

  • Buck Hodges

    Team Foundation Beta 3 Virtual PC is headed your way

    The beta 2 Virtual PC image was hugely popular.  The new Team Foundation beta 3 VPC image is now making its way up to MSDN.  So, later today or Monday you'll be able to download and run a single-server and client beta 3.  Just make sure you have plenty of RAM since you'll be running everything on one machine (say 2GB+).
  • Buck Hodges

    Beta 3 known bug when comparing large files: "Invalid access code (bad parameter)."


    In the forum, Carl Daniel reported getting the message "Invalid access code (bad parameter)" when comparing two different versions of a file in Team Foundation Source Control Beta 3.

    Unfortunately this is a bug that was discovered and fixed after beta 3 was released.  The problem is that large files (on the order of 500K) will crash the diffmerge.exe tool.  I'm not certain as to the exact size that begins to trigger the problem.

    If you hit this bug, you'll need to work around it by using another diff tool until a newer public release fixes the problem (the upcoming beta 3 refresh will still have this bug).  Of course, you could also reduce the size of the file, but that's not often an option.

  • Buck Hodges

    September dogfood statistics


    You can find the latest dogfood statistics on Brian's blog.

    [Update 10/12]  John Lawrence also has the statistics as usual, including Excel charts.  I saw Brian's, and I didn't think to check there.

  • Buck Hodges

    SQL error in get with beta 3


    On the forum, a couple of users have run into this issue with get, so I thought I would mention it here.

    There's a known issue in beta 3 where mapping a server path to a local path that exceeds the NTFS limit results in a SQL error message.  The RTM code will give you a nice message to that effect rather than the SQL error message.

    A database error occurred (SQL error 8152) ---> String or binary data would be truncated.

    MyServer.TFSVersionControl..prc_Get: Database Update Failure - Error 8152 executing EXECUTESQL statement for #versionedItems

    The statement has been terminated.

    If you run into this problem, you can fix it by editing your workspace mappings to change the local path to be shorter.

    For example, if you have "$/project/some_path" mapped to "c:\documents and settings\user\visual studio projects\some_path" then change the local path to something shorter, such as "c:\projects\some_path" and then run get again.  To modify your mappings in VS, use File -> Source Control -> Workspaces, select your workspace, and click Edit.

  • Buck Hodges

    Ed Hintz has started blogging

    Ed Hintz has started blogging with a post that describes some of the differences between working with SourceSafe and working with TFS.  Ed's the dev lead for the source control client team and is the person to whom I report.  So, check it out and be sure to let him know about the things you do and don't like in the TFS source control integration for VS 2005.  Your feedback will not likely change v1 at this point, but if you want to influence the next release, now is the time to speak up.
  • Buck Hodges

    TFS version control command line: tf.exe


    For folks who like command lines or those who've found the typical command line experience a little spartan, you should try tf.exe.

    One interesting feature of our command line is that it uses dialogs for a number of commands when you are running it interactively (i.e., you don't specify /noprompt or /i).  For instance, you get the same check-in dialog from the checkin command in tf.exe as you get from VS.

    The following commands bring up the same dialogs you'd find in VS.

    • changeset
    • checkin
    • difference runs external diff viewer
    • get will take you to the conflict dialog as necessary
    • history
    • resolve
    • shelve
    • unshelve
    • view runs the associated editor
    • workspace

    That makes working with the command line a lot more convenient than you might otherwise think.  You can find the command line docs on MSDN at http://msdn2.microsoft.com/en-us/library/cc31bk2e(en-us,vs.80).aspx.

  • Buck Hodges

    Brian Harry posts about the changes between beta 2 and beta 3


    A while back I wrote a little about what's changed since beta 2 and the release of beta 3.

    Brian Harry, the person who heads Team Foundation (he is Product Unit Manager), has just written the post about what changed.  In What's new with TFS Beta 3?, he covers the whole product, as you might expect.  You'll want to read it.

    One of the things he mentions is something new, tfpt.exe.  That is a power toy that provides some very useful features that didn't make it into the regular product.  We've been using it internally now for a little while.  I'll post more about it when it is available in the next couple of weeks.

    • merging changes in a shelveset with changes in you workspace
    • rolling back a changeset
    • checking out all writable files in your workspace that aren't checked out
    • a dialog focused on code reviews
    • undoing unchanged files
    • getting just the files in a particular changeset
  • Buck Hodges

    Using Source Code Control in Team Foundation


    Chris Menegay's article on MSDN, Using Source Code Control in Team Foundation, provides a good overview of some of the major features.

    As a part of Visual Studio 2005 Team System and the new Team Foundation Server, Microsoft is providing a true enterprise-class source code control system. Team Foundation Version Control (TFVC) is provided as part of Team Foundation Server and offers integrated source control for Visual Studio 2005. Make no mistake about it: TFVC does not share any heritage with Visual SourceSafe. TFVC was written from the ground up to solve limitations of using VSS on large development projects. Instead of relying on a file system as the repository, TFVC leverages Microsoft SQL Server 2005 as a robust, scalable, high-performance storage mechanism.

    Team Foundation Version Control provides all of the basic functionality of other source control mechanisms and most of the enhancements listed for Visual SourceSafe 2005. In addition, TFVC provides new advanced feature, including Shelving, checkin policies, and integration with the new work item tracking system. These features are described later in this article.

  • Buck Hodges

    VSS converter for TFS beta 3

    Akash Maheshwari, PM for the source control converters for TFS, has posted a set of articles on using the VSS converter with TFS beta 3.  You'll want to check that out if you are converting from VSS, because that's the most up-to-date source of information.
Page 19 of 23 (570 items) «1718192021»