Buck Hodges

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

Posts
  • Buck Hodges

    Validating XML characters in SOAP messages

    • 1 Comments

    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

    • 0 Comments

    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

    • 2 Comments

    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

    • 1 Comments
    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

    • 4 Comments

    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.

    Microsoft.TeamFoundation.Client
    Microsoft.TeamFoundation.Common
    Microsoft.TeamFoundation.VersionControl.Client
    Microsoft.TeamFoundation.VersionControl.Common

    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;
                try
                {
                    // 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.
                    Console.Error.WriteLine(e.Message);
                    Environment.Exit(1);
                }
    
                if (items.Length == 0)
                {
                    Console.WriteLine("There are no items for " + path);
                }
                else
                {
                    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

    • 14 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.

    D:\ws1>tree
    Folder PATH listing for volume Dev
    Volume serial number is 0006EE50 185C:793F
    D:.
    ├───A
    └───B

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

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

    D:\ws1>d:\LabelHistory\LabelHistory\bin\Debug\LabelHistory.exe
    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

    D:\ws1>d:\LabelHistory\LabelHistory\bin\Debug\LabelHistory.exe
    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
    Foo@$/testproj/A

    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.

    Microsoft.TeamFoundation.Client
    Microsoft.TeamFoundation.Common
    Microsoft.TeamFoundation.VersionControl.Client
    Microsoft.TeamFoundation.VersionControl.Common

    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;
                try
                {
                    // 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.
                    Console.Error.WriteLine(e.Message);
                    Environment.Exit(1);
                }
    
                if (labels.Length == 0)
                {
                    Console.WriteLine("There are no labels for " + path);
                }
                else
                {
                    foreach (VersionControlLabel label in labels)
                    {
                        // Display the label's name and when it was last modified.
                        Console.WriteLine("{0} ({1})", label.Name,
                                          label.LastModifiedDate.ToString("g"));
    
                        // 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();
                    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();
                    Console.WriteLine("Examples: labelhist c:\\projects\\secret\\notes.txt");
                    Console.WriteLine("          labelhist $/secret/notes.txt");
                    Console.WriteLine("          labelhist c:\\projects\\secret\\notes.txt $/secret");
                    Environment.Exit(1);
                }
    
                // Figure out the server based on either the argument or the
                // current directory.
                WorkspaceInfo wsInfo = null;
                if (args.Length < 1)
                {
                    path = null;
                }
                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 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]);
                    }
                    else
                    {
                        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

    • 0 Comments

    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

    • 7 Comments
    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)."

    • 0 Comments

    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

    • 0 Comments

    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

    • 0 Comments

    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

    • 0 Comments
    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

    • 0 Comments

    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

    • 0 Comments

    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

    • 2 Comments

    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

    • 0 Comments
    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?

    • 0 Comments

    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

    • 1 Comments

    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

    • 2 Comments

    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!

    • 23 Comments

    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

    • 11 Comments
    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

    • 3 Comments

    [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

    • 7 Comments

    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.

    Microsoft.TeamFoundation.Build.Client.dll
    Microsoft.TeamFoundation.Build.Common.dll
    Microsoft.TeamFoundation.Client.dll
    Microsoft.TeamFoundation.VersionControl.Client.dll
    Microsoft.TeamFoundation.VersionControl.Common.dll
    Microsoft.TeamFoundation.WorkItemTracking.Client.dll

    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 ()
        {
        }
    
        [SoapDocumentMethod("http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03/Notify", 
                            RequestNamespace = "http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03")]
        [WebMethod]
        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();
            Xmldoc.LoadXml(eventXml);
    
            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;
            do
            {
                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;
            workItem.Save();
        }
    }
    
  • Buck Hodges

    Doug Neumann on Channel 9

    • 1 Comments

    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?

    • 3 Comments

    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;
            }
            else
            {
                return encoding.GetByteCount(text);
            }
        }

Page 19 of 23 (561 items) «1718192021»