Buck Hodges

Visual Studio ALM (VSALM, formerly VSTS) - Team Foundation Service/Server (TFS) - MSDN

September, 2005

  • 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.
  • Buck Hodges

    Why are there two Source Control entries on the File menu?


    If you add the Code Analysis check-in policy to your Team Project, you'll see two entries for Source Control on the File menu in VS, as shown below.

    All of the standard menu items for TFS source control are under the second Source Control entry.  The issue is cosmetic and is related to a change we made in the TFS source control provider used in VS.  This should be fixed by the time version 1 is released.

    On a related note, Eric Lee has a post regarding an issue with solutions that were bound to source control in TFS beta 2.  If you have a solution was originally bound to source control in beta 2, you can remove the bindings by editing the .sln file, as he describes.  Alternatively, if you open your solution without editing it, you should get a dialog stating that the "associated source control plug-in is not installed or could not be initialized."  Choosing to "permanently remove source control association bindings" will also remove the bindings from the solution file.

    After the solution file no longer has the old bindings, you can then re-bind the solution using File -> Source Control -> Change Source Control if it's already checked in or right-click on the solution and choose Add to Source Control to put it in TFS beta 3.

  • Buck Hodges

    The 10,000th Changeset


    Back on July 13, I wrote about the dates of changeset "milestones" in our dogfood system.  Today we hit changeset 10,000.  The time between 9000 and 10000 was longer than usual because of check-in restrictions in place leading up to beta 3 (bug fixes had to be individually reviewed and approved in ask mode).

    Here's the full list.  The rate of changesets being created should increase as we continue to add more teams to the system.

    Changeset 10000 was checked in on September 26
    Changeset 9000 was checked in on September 2
    Changeset 8000 was checked in on August 16
    Changeset 7000 was checked in on July 30
    Changeset 6000 was checked in on July 15
    Changeset 5000 was checked in on June 29
    Changeset 4000 was checked in on June 13
    Changeset 3000 was checked in on May 20
    Changeset 2000 was checked in on April 26
    Changeset 1000 was checked in on March 15
    Changeset 1 (creation of the server - that upgrade started with a fresh server installation) was checked in on December 10, 2004

  • Buck Hodges

    Active Directory is no longer required with Team Foundation Beta 3


    There have been a lot of requests from folks wanting to use TFS without Active Directory.  Since several questions and answers in comments on Jeff Beehler's blog dealt with this, I thought it's worth mentioning in a post that TFS beta 3 supports workgroup installations, and Active Directory is not required in that configuration.

    [Update 09/22/05]  Doug's comment below addresses another long-standing issue: "Additionally, beta 3 now supports Windows 2000 Active Directories as well as the previously supported Windows Server 2003 version."

  • Buck Hodges

    Team Foundation Beta 3 has been released!


    Today we signed off on Team Foundation Beta 3!  If you used beta 2, beta 3 is a vast improvement.  Beta 3 should hopefully show up on MSDN in about two days.  You may remember that beta 3 has the go-live license and will be supported for migration to the final release version 1, which means this is the last time you have to start from scratch.

    With beta 3, single-server installation is once again supported!  I know many people didn't install the July CTP because of the lack of a single-server installation.  With each public release, installation has gotten easier and more reliable, and this is the best installation thus far.

    I wrote about what changed between beta 2 and the July CTP.  That's still a good summary.  Between the July CTP and beta 3, we fixed a lot of bugs, further improved performance across the product, improved the handling of authenticating with the sever using different credentials (e.g., you're not on the domain), improved installation, and more.

    If you have distributed teams, be sure to try out the source control proxy server.  It's one of the features we have to support distributed development.

    While you are waiting on TFS to show up, you'll want to make sure you already have Visual Studio 2005 Team Suite Release Candidate (build 50727.26) and SQL Server 2005 Standard (or Enterprise) Edition September CTP (build 1314.06, which uses the matching 2.0.50727.26 .NET framework)).

    TFS beta 3 is build 50727.19.  The reason the minor number is different than the VS RC minor number is due to the fact that TFS beta 3 was built in a different branch.  The major build number stopped changing at 50727 (July 27, 2005 build) for all of Visual Studio, and only the minor number changes now.

    Here's a list of my recent posts that are particularly relevant to beta 3.

    This one will need to be updated (URLs changed):  TFS Source Control administration web service.

    [Update 9/22/05]  Updated links and SQL info.

  • Buck Hodges

    Working remotely with TFS Version Control

    Here in North Carolina, we have a 10Mb connection to the outside world (it was a 3Mb connection until a few months ago), so we know what it's like to use TFS remotely.  In addition to minimizing the number of requests from the client to the server, TFS Version Control contains several features that aid in working in a situation where the connection to the server is much slower than the local network: compressed files, compressed SOAP responses, and a caching proxy server.
    Every file that we upload as part of checking in or shelving is compressed using GZip.  If a file is larger after being compressed, which may be due to it being in a compressed format (e.g., ZIP or JPEG) already or being encrypted, the file will be uploaded without being compressed.  When files are downloaded, they are still compressed as they were when they were uploaded.
    Communication between the client and server in TFS uses HTTP for everything, and it uses SOAP for everything other than file uploads and downloads.  We support IIS 6 compression of the SOAP responses (requires IIS settings for asmx pages -- I expect this is in the installation guide, but I haven't made time to go check), so the communication with the remote server is compressed.  Since SOAP is XML, responses compress very well.
    The caching proxy in version 1 caches versions of files, and it does not handle any other parts of the client-server communications.  When a user configures a client to use a proxy server (in VS, Tools -> Options, click on Source Control and then Team Foundation Source Control to get to the proxy settings), the client still calls the server for the list of files to download (e.g., diff, get, view, undo) and calls the proxy server to download the file contents.
    The first user to download a file must wait until the file is transferred over the remote link, but subsequent downloads are served from the proxy's local disk copy.  To prevent the lag for the first user, you could, for example, set up a workspace that exists for the purpose of populating the cache by having a Windows task scheduled to run "tf get" every so often (say 30 minutes) or hook into the check-in event from the mid-tier and kick off a get in the workspace (see Continuous Integration Demo Code from Doug Neumann's TLN301 PDC Talk for an example of hooking into the check-in event generated by the app tier).
    The amount of disk space used by the proxy is configurable, and it removes the least recently used files first when it needs to reclaim disk space.  With large hard drives being cheap, it's not hard to have a caching proxy server cache every version of every file in the server and not have to delete anything.
    Here in North Carolina, we have a proxy server set up that is on our 100Mb network, so downloads are local while the rest of the communication is still over the WAN link.  We also take advantage of the IIS compression for the SOAP responses (it's turned on for our dogfood server).
    I wrote back in March that our experience with using TFS had been good, and it's gotten significantly better since then due to features like the proxy, compressed SOAP responses, and the performance optimizations that have been made.
    [Update 10/01/05]  When you install the server, SOAP response compression is automatically configured.  You don't need to make any changes to take advantage of it.
  • Buck Hodges

    Outlook macro to create work item and changeset hyperlinks


    [NOTE: If this post looks truncated, scroll down or make the browser window wider.  The style sheet causes this.]

    Ed Hintz, a dev lead on the TFS Version Control team, sends a lot of email with TFS work item numbers.  Work items can be viewed (not edited) in a web browser using an URL constructed from the server name and the work item number.  Our dogfood system is a single server, so the server is always the same.  So, Ed wrote a macro for Outlook that will convert the current selection to a hyperlink to the work item.

    Here's the code for the macro, which he bound to Alt+L.  The hyperlinks generated will work for beta 3, but you would need to tweak the hyperlink for earlier releases.

    Sub LinkToWorkItem()
    ' Convert the current selection to a work item hyperlink
        ActiveDocument.Hyperlinks.Add Anchor:=Selection.Range, Address:= _
            "http://TFserver:8080/WorkItemTracking/Workitem.aspx?artifactMoniker=" _
    & Selection.Text, _
            SubAddress:="", ScreenTip:="", TextToDisplay:=Selection.Text
    End Sub

    To do the same thing for changesets, use the following.

    Sub LinkToChangeset()
    ' Convert the current selection to a changeset hyperlink
        ActiveDocument.Hyperlinks.Add Anchor:=Selection.Range, Address:= _
            "http://TFserver:8080/VersionControl/VersionControl/Changeset.aspx?artifactMoniker=" _
    & Selection.Text & "&webView=true" _
            , SubAddress:="", ScreenTip:="", TextToDisplay:=Selection.Text
    End Sub

    If you have never created a macro in Outlook, create a new mail message, click in the body (otherwise, the Macros menu is disabled), go to Tools -> Macro -> Macros, enter the name "LinkToWorkItem" in the dialog's text box, and click Create.  In the Visual Basic Editor that opens up, paste the body of the LinkToWorkItem macro into the subroutine, save, and close the VB Editor.  To associate it with Alt+L, go to Tools -> Customize, click the Keyboard button, scroll down to Macros in the Categories list box, click in the "Press new shortcut key" text box, and press Alt+L.  Now click Assign, Close, and Close.  In the new mail message you have up, type a number, select it, and hit Alt+L to test it.

    Now when you want to turn a plain number into a work item or changeset link, highlight the number and run the macro via the shortcut you've assigned.

    [Update 10/03/05]  Updated code comment.

  • Buck Hodges

    Continuous Integration Demo Code from Doug Neumann's TLN301 PDC Talk


    Doug Neumann's TLN301 presentation, VSTS: Behind the Scenes of Visual Studio 2005 Team Foundation Server (slides), featured a demonstration of how to use the server's check-in event notification to kick off a build for a continuous integration build system using Team Build.  A number of people asked for it, so we've decided to post it here.

    Doug's demonstration used the July CTP, but since beta 3 will hopefully be released this week, the code has been modified to run on beta 3.  You'll need to create a web service and put the following code into it.  Here are the assemblies you'll need to reference.


    The code is intentionally simplified to meet the needs of a demo (e.g., a real continuous integration system would need more intelligence in handling check-in events that come in while the current build is running, etc.), but it's a good example of how to hook into the Team Foundation server's events and build useful extensions.

    Once you've built and deployed your web service using VS 2005, you'll need to add a subscription for your web service.  The check-in event is sent to your continuous integration web service via SOAP.  The following command, with changes as necessary for the name of your machine (here, I use localhost), must be run on the application tier to add an event subscription for your service.

    bissubscribe /eventType CheckinEvent /userId mydomain\myusername /address http://localhost:8080/ContinuousBuild/Service.asmx /deliveryType Soap /domain localhost

    Now when you check code into your server, your continuous integration service will kick off a build.

    The Team Build team plans to post a more elaborate continuous integration example.

    [UPDATE 2/20/06]  I updated the version numbers in the SoapDocumentMethod attribute to work with RC and RTM releases.

    using System;
    using System.Collections;
    using System.Collections.Generic;
    using System.Collections.Specialized;
    using System.ComponentModel;
    using System.Configuration;
    using System.Diagnostics;
    using System.Globalization;
    using System.IO;
    using System.Reflection;
    using System.Threading;
    using System.Web;
    using System.Web.Services;
    using System.Web.Services.Protocols;
    using System.Xml;
    using System.Xml.Serialization;
    using Microsoft.Win32;
    using Microsoft.TeamFoundation.Build.Common;
    using Proxy = Microsoft.TeamFoundation.Build.Proxy;
    using Microsoft.TeamFoundation.Client;
    using Microsoft.TeamFoundation.WorkItemTracking.Client;
    using Microsoft.TeamFoundation.WorkItemTracking.Common;
    [WebService(Namespace = "http://tempuri.org/")]
    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    public class Service : System.Web.Services.WebService
        public Service ()
                            RequestNamespace = "http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03")]
        public void Notify(string eventXml)     // Do not change the name of this argument.
            ThreadPool.QueueUserWorkItem(CallBuild, eventXml);
        public void CallBuild(object state)
            string eventXml = (string)state;
            // De-serializing the event
            XmlDocument Xmldoc = new XmlDocument();
            string teamProject = Xmldoc.DocumentElement["TeamProject"].InnerText;
            string owner = Xmldoc.DocumentElement["Owner"].InnerText;
            // NOTE: hard-code info for demo
            string teamFoundationServer = "http://localhost:8080";
            string buildType = "Continuous Integration Build";
            string buildMachine = "localhost";
            string buildDirectoryPath = "c:\\builds";
            Proxy.BuildController controller = Proxy.BuildProxyUtilities.GetBuildControllerProxy(teamFoundationServer);
            Proxy.BuildStore store = Proxy.BuildProxyUtilities.GetBuildStoreProxy(teamFoundationServer);
            Proxy.BuildParameters buildParams = new Proxy.BuildParameters();
            buildParams.TeamFoundationServer = teamFoundationServer;
            buildParams.TeamProject = teamProject;
            buildParams.BuildType = buildType;
            buildParams.BuildDirectory = buildDirectoryPath;
            buildParams.BuildMachine = buildMachine;
            string buildUri = controller.StartBuild(buildParams);
            // wait until the build completes
            BuildConstants.BuildStatusIconID status;
            bool buildComplete = false;
                Proxy.BuildData bd = store.GetBuildDetails(buildUri);
                status = (BuildConstants.BuildStatusIconID)bd.BuildStatusId;
                buildComplete = (status == BuildConstants.BuildStatusIconID.BuildSucceeded ||
                    status == BuildConstants.BuildStatusIconID.BuildFailed ||
                    status == BuildConstants.BuildStatusIconID.BuildStopped);
            } while (!buildComplete);
            if (status == BuildConstants.BuildStatusIconID.BuildFailed)
                // create a workitem for the developer who checked in
                CreateWorkItem(teamFoundationServer, teamProject, owner);
        public void CreateWorkItem(string server, string projectName, string owner)
            TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(server);
            WorkItemStore store = (WorkItemStore) tfs.GetService(typeof(WorkItemStore));
            WorkItemTypeCollection workItemTypes = store.Projects[projectName].WorkItemTypes;
            // Enter the work item as a bug
            WorkItemType wit = workItemTypes["bug"];
            WorkItem workItem = new WorkItem(wit);
            workItem.Title = "The changes submitted have caused a build break - please investigate";
            string[] ownerSplit = owner.Split('\\');
            owner = ownerSplit[ownerSplit.GetLength(0) - 1];
            workItem.Fields["System.AssignedTo"].Value = owner;
            workItem.Fields["Microsoft.VSTS.Common.Priority"].Value = 1;
  • Buck Hodges

    Doug Neumann on Channel 9


    Doug Neumann, one of our esteemed Program Managers, is in a short video on Channel 9 talking about our office, version control, the proxy, etc.  He and Mario, our other version control PM, are at PDC this week.

    Doug Neumann - Source Code control guy on VSTS team

  • Buck Hodges

    How wide is a string when displayed in the console window?


    Not too long ago, I had to fix the command line output for tf.exe, the Team Foundation Version Control command line app, so that output would be formatted properly for console windows (cmd.exe) using double-byte code pages.

    The code originally computed the output display width as the length of the string.  However, that's not correct when the code is running on a Japanese Windows system, for example.  Whereas English letters all take up one position in the console window, double-byte characters are twice as wide and take two positions.  The original code produced really bad looking output.

    To make sure that I got the right solution, I asked Aldo, an internalization PM.  The solution was to use the number of bytes that would result from converting the string to a byte array using the console window's code page.  Each English letter results in a byte, and each Japanese character results in two bytes.

    For single-byte code pages, the double-byte characters only take up one position, because they get munged due to the console not being able to display them.  The .NET System.Text.Encoding class handles properly converting strings to and from byte arrays.  Of course, I didn't need an actual byte array.  Fortunately, the Encoding class has a method called GetByteCount() that gives the information I need.

    The end result is the following simple method that calculates the display width of a string in the console's encoding.

        static int CalculateConsoleWidth(String text)
            Encoding encoding = Console.Out.Encoding;

            if (encoding.IsSingleByte)
                return text.Length;
                return encoding.GetByteCount(text);

  • Buck Hodges

    How TFS Version Control determines a file's encoding


    TFS Version Control will automatically detect a file's encoding based upon the following.

    • First, a file with a Unicode byte order mark (BOM) is added as that particular type (UTF-8, UTF-16 big endian, UTF-16 little endian, etc.).
    • If a file doesn't have a BOM, we check for an unprintable ASCII character in the first 1 kilobyte of the file.  If there is no unprintable ASCII character in there, the encoding is set to the current code page being used, which is Windows-1252 on US English Windows systems.
    • If an unprintable character is detected, the file is detected as being binary.  The unprintable ASCII characters detected are in the range of 0 - 0x1F and 0x7F excluding 0x9 (TAB), 0xA (LF), 0xC (FF), 0xD (CR), and 0x1A (^Z).

    The only exception to the foregoing is PDF files.  Those are always detected as binary because they are so common and can be all text in the first 1 kilobyte with binary streams later in the file.  The detection is based on the signature, "%PDF-", that always appears at the start of a PDF file.

    So, if you take a file that is in the euc-jp encoding and add it to source control on a US English Windows system, it will be added as Windows-1252 unless you specify a different encoding with the /type parameter on the add command (e.g., "tf add /type:euc-jp file.txt").  If the file is already in source control, use the edit command's /type option to change the encoding.

    Within Visual Studio 2005, you can change a committed file's encoding by navigating to it using Source Control Explorer (View -> Other Windows -> Source Control Explorer), right-clicking on the file, and choosing Properties.  On the General tab, click on the Set Encoding button and choose the encoding or click on the Detect button and have Version Control detect the encoding using the process described above.

    Because changing the encoding requires pending a change on the file, you must have the file in your workspace.  Files and folders in Source Control Explorer that are in grey text (rather than black text) are either cloaked or not mapped in your workspace or the workspace does not "have" the file (the server keeps track of what files are in your workspace).

    Unfortunately, TFS does not support changing the encoding of a pending add.  If you need to do that, you will have to undo the pending add, and then re-add the file using the command line and specify the /type option.

    [UPDATE 6/8/2012] The TFS client (Visual Studio/Team Explorer) in 2012 has changed how this is done for file merges (e.g., when resolving conflicts).

    1. VS 2012 reads the entirety of the source, target, and base files during automerge. This helps in the case of a UTF-8 file without a BOM where the first non-ASCII character is after the first 1024 bytes of the file.We detect a file that does not have a BOM as UTF-8 if:

    • There is at least one non-ASCII character (Unicode codepoint > 127)
    • There are no byte sequences in the file that are invalid in UTF-8. If you read http://en.wikipedia.org/wiki/Utf-8, you will see that all code points > 127 in UTF-8 must be represented as multibyte sequences following a very specific pattern. It would be unlikely for a meaningful non-UTF-8 file with non-ASCII characters to meet this criteria
    • If one of the above criteria is not met, we use the “fallback” encoding.

    2. In VS 2012, the fallback encoding is the server encoding. This allows you to override our heuristic in the scenario where:

    • you have a file that you would like to be encoded as UTF-8 without a BOM
    • but it does not have any non-ASCII characters yet.

    In previous versions we would fall back to the default system code page (e.g. Windows-1252). In VS 2012, if you set the server encoding to UTF-8, automerge will use UTF-8 instead.

  • Buck Hodges

    Team Foundation Version Control client API example


    [Update 3/16/2006]  I have decided to remove this version to reduce confusion.  Please see http://blogs.msdn.com/buckh/archive/2006/03/15/552288.aspx for the RTM v1 example.

Page 1 of 1 (13 items)