Buck Hodges

Visual Studio Online, Team Foundation Server, MSDN

Posts
  • Buck Hodges

    TFS Version Control post summary

    • 3 Comments

    Now that the RC is out, I thought I'd post a summary with links to version control posts from the last several months that I think are relevant.

    Clark Sell posted a VSTS JumpStart with useful links as well.

    Here are some posts from James Manning you may find useful.

    For those of you out there who want to add your own "power toy" to enhance the TFS version control experience in VS, check out How to Write a Team Foundation Version Control Add-in for Visual Studio by Ed Hintz, which also includes adding TFS assemblies to VS.  You could add features like baseless merges, merge history, listing the pending changes in all workspaces or a particular workspace, and deleting other users workspaces (if you have permission).  You could add a check out command that gets the latest version of a file before checking it out.  Or maybe you'll come up with something more interesting.

    There are more links that I should include, but that's enough for now.

  • Buck Hodges

    Using Team Foundation in Eclipse with the TeamPrise plug-in

    • 0 Comments

    I'm still catching up on what's been going on, and I found this on Grace Francisco's blog.  I've highlighted the end of the summary where it mentions using TeamPrise on Linux.

    MSDN Webcast: Accessing Visual Studio 2005 Team System Using the Teamprise Plug-In for Eclipse (Level 200)

    Find out how you can use the Teamprise Plug-in for Eclipse to access the source control features of Microsoft Visual Studio 2005 Team System from within the Eclipse integrated development environment (IDE). In this webcast, we show you how to add new Eclipse projects to a Microsoft Visual Studio 2005 Team Foundation server, import existing projects from Team Foundation Server into Eclipse, and keep projects synchronized. We also look at the Teamprise Explorer client on a Linux virtual machine.

     

  • Buck Hodges

    How to upgrade to Team Foundation RC

    • 1 Comments

    The Team Foundation RC should be available for download sometime today, and Jeff Beehler provided a high-level description of what's changed.  His first point is the most significant.  There are many, many bug fixes in the RC compared to beta 3.  For version control, merge has improved the most.  It's quite a bit faster and more robust.

    Rob Caron has posted information on upgrading from beta3 refresh to the RC, including the Team Foundation RC Installation Guide.  Those with beta 3 installed will need to upgrade their servers to beta 3 refresh to then upgrade to the RC.  Clients just need the new RC client installed, regardless of the beta 3 variant currently installed.

  • Buck Hodges

    VSTS Load Test team bloggers: Ed Glas, Bill Barnett, Josh Christie

    • 1 Comments

    One of the many great parts of Visual Studio Team System is Load Testing.  As one of the three original projects here in the Durham, North Carolina office, it was known as Ocracoke originally (Version Control was Hatteras, and Work Item Tracking was Currituck -- all three are islands in the North Carolina Outer Banks).

    The Load Testing team continues to ramp up on blogging.  In addition to Josh Christie, Ed Glas, group manager, and Bill Barnett, developer, have started blogging.  Other team members that don't have their own blogs will also be contributing posts.  It's a great way to learn about Load Testing.  Check it out!

  • Buck Hodges

    Baseless merges now record history

    • 5 Comments

    Back in June, I wrote a post on using baseless merges to establish a merge relationship between two items where neither was branched from the other.  A week after I posted it, I had to go back and change it to say that baseless wouldn't record merge history for v1, and thus you would only be able to merge items where one was a branch of the other.

    I'm happy to say that's been fixed both for the RC (available tomorrow) and RTM (available in March)!

    So, if you have two folders, projectX and skunkWorksX, where neither is a branch of the other, you can establish a merge history between the two by running "tf merge /baseless projectX skunkWorksX /r" (or you can re-order the source and target, according to the direction in which you want to initially move changes).  When you are done resolving the conflicts and check it in, you will be able to merge normally between the two with "tf merge projectX skunkWorksX /r" or "tf merge skunkWorksX /r" depending upon which direction you need to propagate changes.

    In v1 you have to use the command line to perform baseless merges.  Also, items that did not originally have a branch relationship will not show up in the Source Control Explorer in VS as able to be merged (you'll have to use the command line).  Those are pretty minor tradeoffs for a really useful feature, though.

  • Buck Hodges

    How to add the Team Foundation assemblies to the .NET tab in the VS Add Reference dialog

    • 14 Comments

    To write an app using the Team Foundation API, you're going to need to reference assemblies that are in the GAC.  It's not possible to add a reference to a .NET assembly in the GAC in VS when you need to add a reference to an assembly.

    The GAC'ed Team Foundation assemblies are also copied to the PrivateAssemblies folder under the VS directory.  When you want to add a reference to a TFS assembly in VS solution, you can choose Browse and find the assembly.

    To make it more convenient, you can also add the TFS assemblies to the .NET tab in the Add Reference dialog.  This knowledge base article describes how to add an assembly to the list in the .NET tab.

    Based on that, here's a simple batch script that will add all of the GAC'ed Team Foundation assemblies to the list.  There are probably assemblies you'll never need to use in this list, so feel free to trim it down.  You can copy the text to a file called register.bat and run it.  The batch script assumes that you installed VS in the normal Program Files directory.  Since this script modifies your registry, all of the usual disclaimers apply, you should back it up beforehand, etc.

    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.Build.Common /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.Client /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.Common /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.Common.Library /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.VersionControl.Client /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.VersionControl.Common /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.VersionControl.Common.Integration /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.WorkItemTracking.Client /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.WorkItemTracking.Client.Cache /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.WorkItemTracking.Client.Provision /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.WorkItemTracking.Client.QueryLanguage /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.WorkItemTracking.Client.RuleEngine /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f
    reg add HKCU\Software\Microsoft\.NETFramework\AssemblyFolders\Microsoft.TeamFoundation.WorkItemTracking.Proxy /ve /d "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" /f

    After running the script, you should see the GAC'ed Team Foundation assemblies listed in the .NET tab.

    [Update 1/12]  I fixed some errors in the first couple of paragraphs.

  • Buck Hodges

    Migrating CVS and Subversion repositories to Team Foundation Server

    • 4 Comments

    A number of users have asked about converting existing CVS and Subversion repositories to Team Foundation Server.  While we have no plans to produce such, we had hoped third parties would.  Today someone from Component Software posted an announcement of such a converter.

    Here's the description from their web page.

    CS-Converter is a powerful and reliable conversion tool, used to migrate from various legacy version control systems (such as RCS, CVS, Subversion and Visual SourceSafe) to Microsoft Team Foundation Version Control (TFVC) system.

    Disclaimer: I don't have any relationship with the company, haven't tried the software, am not endorsing it, etc., etc.

    [UPDATE 10/20/2009] With the Component Software product being discontinued, I wanted to mention that there is another company now with a tool to convert CVS and subversion to TFS called Timely Migration.

  • Buck Hodges

    Locks based on file types (extensions) and shelving

    • 4 Comments

    Recently, someone asked about locks, shelving, and buddy builds (i.e., shelving your changes and unshelving and building them in another workspace to make sure everything builds cleanly).

    I am trying to add a number of files into our source control.  The list of files I want to add contains a few each of .ico and .bmp, and one .xls files, all which get locked (locked to prevent check-out) when I add them, presumably because they cannot be merged if someone else checks them out and changes them.

    The fact that they get locked seems to deny the possibility of buddy building, even on my own second machine, because they are locked on a by-workspace rather than by-user basis.

    I tried selecting the binary items in the hierarchy under the Source Control Explorer, and right-clicking to the “unlock” command, but it always says that the file could not be found in my workspace.

    What am I missing?  A preference setting or checkbox somewhere that does not lock added binary files?  Is there some way to turn off or override my own lock?  Is it really not possible to unshelve shelvesets containing binary files to a second machine?

    Locking and shelving, while keeping the changes in your workspace, don't mix.  The files that are configured to be locked via file type extension (in VS, Team -> Team Foundation Server Settings -> Source Control File Types) are locked exclusively.

    An exclusive checkout lock prevents any other changes from being pended on the file involved.  The file type locking mechanism prevents user from unlocking files that are locked via that mechanism.  So, to do a buddy build, you would need to shelve and undo, which is best accomplished by either unchecking the “Preserve local changes” checkbox in the GUI shelve dialog or using the /move option on the shelve command.  Alternatively, you can change the file types to allow multiple checkout.

    The problem is even worse for users where exclusive checkout is turned on for an entire team project, as even plain text files are locked exclusively in that case.  As with the file type extension locking mechanism, users cannot unlock files that are locked due to the team project setting.  When you shelve, you need to move the changes to the shelveset (don't keep them in your workspace).

    For us, the file type locking causes problems both with buddy builds and with a check-in system we use called gauntlet.  With gauntlet, we shelve our changes and submit them to gauntlet for it to build them and check them in.  It can't unshelve any item that requires an exclusive lock if you still have the pending change in your own workspace.  As a result, we've turned off exclusive checkout based on file extensions by changing each to allow multiple checkout.

  • Buck Hodges

    Disabling or changing output colors used by the command line (tf.exe)

    • 2 Comments

    In the forum, a user asked how to turn off the colors used in the output of the version control command line for Team Foundation (tf.exe).  I thought I'd repost it here.

    Question

    When tf.exe (beta 3 refresh version) displays an error message the text is colored in yellow on black. My command prompt windows usually have black text on white background. Is it possible to let tf. exe display all output without changing the color, e.g. via an environment variable?

    Answer

    You can change or turn off the coloring by changing the settings in tf.exe.config (in the same location as tf.exe).

    Here is the list of display settings.

    Display.FallbackWidth - the width the command line uses when the output is not going to the console; this is used in column calculations, separators and defaults to 80
    Display.DisableColors - turns colors on or off (defaults to true)
    Display.ErrorBackground - the background of error or warning text (defaults to black)
    Display.ErrorForeground - the foreground of error or warning text (defaults to yellow)
    Display.InfoBackground - the background of informational text (defaults to black)
    Display.InfoForeground - the foreground of informational text (defaults to cyan)

    You can turn off coloring altogether by adding the following to your tf.exe.config file.

       <appSettings>
          <add key="Display.DisableColors" value="true" />
       </appSettings>

    If you simply want to alter the coloring to make it look better, you could use something like the following.  The color choices are black, blue, cyan, darkblue, darkcyan, darkgray, darkgreen, darkmagenta, dark red, darkyellow, gray, green, magenta, red, white, and yellow.

       <appSettings>
          <add key="Display.ErrorForeground" value="blue" />
          <add key="Display.ErrorBackground" value="white" />
       </appSettings>

    Your tf.exe.config file will end up looking something like the following.

    <?xml version="1.0"?>
    <configuration>
      <runtime>
        <gcConcurrent enabled="true" />
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
          <publisherPolicy apply="yes" />
          <probing privatePath="PrivateAssemblies" />
        </assemblyBinding>
      </runtime>

      <appSettings>
        <add key="Display.DisableColors" value="true" />
      </appSettings>

    </configuration>

    [Update 1/7] Fixed formatting issues.

  • Buck Hodges

    Beta TFS MSSCCI plugin now available for VB6, VC6 (not yet VS 2002/2003)

    • 1 Comments

    Brian Harry announced the availability of the beta TFS MSSCCI plugin for VB6, VC6 (not yet VS 2002/2003).

    You can download it at http://www.microsoft.com/downloads/details.aspx?familyid=32202966-EF04-442F-8C5C-88BDF15F551C&displaylang=en.

    Buck

  • Buck Hodges

    How to improve command line performance

    • 7 Comments

    If you are using the tf.exe command line in scripts to convert from another version control system or to run other tasks that involve a lot of calls, there are several factors that have a large impact on the performance.  Other than the command files, all of the following applies to Visual Studio as well, but VS has the significant advantage of amortizing one-time overhead across a long execution time.  The command line pays one-time costs every time it runs, so it's important to minimize those costs when performance matters.

    Check LAN connection settings (applies now and for RTM)

    First, check your LAN connection settings in Internet Explorer (Tools -> Internet Options -> Connections -> LAN Settings).  Often, the best settings are either to have no boxes checked or to have both of the bottom two checkboxes checked, "Use a proxy server" and "Bypass proxy server for local addresses."  The reason is that the .NET 2.0 framework network code gets its settings from the settings in IE.  Prior to the December CTP, there was no way to override this.

    How much difference does it make?  It makes a 1 - 2 second difference per tf.exe execution on our network.  Of course, these settings may not work on your network, either for tf.exe or IE, depending upon your network configuration; you'll need to test it.

    Beginning with the December CTP, there is an optional registry setting that you can use to tell the Team Foundation client to bypass the proxy server without changing your IE settings.  In HKCU (per user) or HKLM (global), you can create the registry entry Software\Microsoft\VisualStudio\8.0\TeamFoundation\RequestSettings\BypassProxyOnLocal of type string with the value "true" to get the improved performance.

    Avoid running tf.exe on the application tier (applies now and for RTM)

    You might think that running tf.exe on the application tier would give you the best performance.  After all, the network communication would be minimized, right?  Well, it doesn't work that way.

    Team Foundation has a registration service that the client uses in order to get to the various services, including version control.  When a client app, such as tf.exe, VS, or your own custom application, needs to use version control, the TF client code must request the service definition from regsistration service on the server.  To avoid constantly requesting service registration information that rarely changes, the client-side registration code maintains a cache and only makes the server call when the cache is out of date.

    However, when the client code executes on the application tier, the client-side registration code detects that it is running on the application tier and does not cache the service registration information.  Additionally, there's a bug (that won't even be fixed for RTM due to being posponed to v2) that results in the client-side registration code requesting the registration information twice.  So, every execution of tf.exe invokes two registration service information requests when run on the application tier.

    The result is that tf.exe is faster when run on a machine other than the application tier (both now and for RTM).  So how much difference does this make?  It can save 1 - 3 seconds.  How much it saves really depends on some additional factors.  The call to get the registration information may take a few hundred milliseconds or so (multiplied by two for the app tier).  The rest of the savings comes from SOAP proxy class not being generated.  The client-side SOAP proxies other than version control use the standard SOAP proxy support provided by the .NET 2.0 framework where the client-side proxy class is generated by wsdl.exe at build time.  At runtime, the framework uses reflection to dynamically generate, compile, and load serialization assembly the first time the proxy class is used.  As you might guess, that's very expensive for the command line.

    The best setup would be a client machine that's connected to an application tier via a fast, local network switch.

    Use NGen with tf.exe (applies to beta 3 refresh and earlier)

    With .NET 2.0, NGen has improved substantially.  NGen generates native image dlls for .NET assemblies and executables (you can find more details on NGen here).  The result is that less time is required to load and run the assemblies.

    The December CTP and beyond will use NGen during setup to create the native images.  For beta 3 and beta 3 refresh, you can use ngen.exe to reduce the time to load and run tf.exe.  You only need to run ngen.exe once.  Bring up a Visual Studio 2005 Command Prompt (Start -> All Programs -> Microsoft Visual Studio 2005 -> Tools -> Visual Studio 2005 Command Prompt), change to the %PROGRAM_FILES%\Microsoft Visual Studio 2005\Common 7\IDE directory and execute the following command.

    ngen install tf.exe

    NGen will examine tf.exe's dependencies and generate native images for them.  The result will be a faster start up time for every execution of tf.exe.  How much time does it save?  This may save up to 200 ms.

    Generate command files for sequences of tf.exe commands (applies now and for RTM)

    Team Foundation Server uses Windows authentication (NTLM) to authenticate users.  That means that every initial request from tf.exe must go through the NTLM handshake.  Since many tf.exe commands make only one or two requests, that means that most requests incur the authentication overhead.  For a long sequence of tf.exe commands, that overhead can really add up.

    If you are going to run a sequence of tf.exe commands, you can put them into a command file.  Preliminary documentation for command files is available here on MSDN.  The documentation refers to some addtional commands that are not available now, such as cd, rem, quit, and exit.  You can also run "tf @" and start typing or piping input as it reads from the standard input stream (experiment with it).

    When you execute a command file, only the first request incurs the authentication overhead.  After that, the authenticated connection is reused[1].  How much time does this save?  Well, there's no quick answer here.  It's the product of the authentication overhead multiplied by the number of authentication requests you can avoid by using command files.  Additionally, it's the runtime startup overhead multiplied by the number of times you would have invoked tf.exe (this isn't nearly as significant if you've used ngen.exe as explained previously).

    Summary

    We've covered the most important command line performance issues that you can control: LAN settings (or TFS registry setting for RC/RTM), not running tf.exe on the application tier, running ngen on the beta 3 tf.exe, and using command files to avoid authentication overhead.  If you follow the recommendations discussed above, the tf.exe performance should be noticeably better.

    ___________

    [1]  Technically, it's the first request on each thread.  Uploads, downloads, and pending adds (if you are adding more than 200 files at a time) use multiple background threads.  If all of the authenticated connections are in use, a thread will open a new connection that must be authenticated.  The authenticated connections are part of a pool (connection group) that are reused as needed.

  • Buck Hodges

    Backing up and restoring Team Foundation

    • 0 Comments

    Rob Caron posted a link to the re-launched VSTS User Education team blog.  It includes a post of the procedures for backing up and restoring Team Foundation Server.  That includes the databases, SharePoint, reports, etc.  It also includes restoring TFS to a different server.  There have been lots of requests for this in the forum, so now's the time to give it a try.

    They have also posted documentation on permissions and the default groups, roles, and permissions.

    Since this is pre-release documentation, be sure to email them with any problems in the documentation.

    [Update 3/2/06]  You can find updated procedures for restoring TFS at http://blogs.msdn.com/vstsue/articles/511396.aspx.

  • Buck Hodges

    Team Foundation Version Control API documentation

    • 7 Comments

    I've mentioned the Team Foundation Version Control client API example before as good way to get started with the API, and there are examples with labels and items too.  You can find documentation for the classes and methods in the Team Foundation Version Control API in the October Visual Studio SDK release.  Once you install it, you can find the Version Control API doc in
    C:\Program Files\Visual Studio 2005 SDK\2005.10\VisualStudioTeamSystemIntegration\Version Control\Object Model (Help 1.x format).zip.

  • Buck Hodges

    The "Filter by solution" button

    • 10 Comments

    You are probably familiar with the Pending Changes window if you've been using Visual Studio with Team Foundation (View -> Other Windows -> Pending Changes).  Have you ever wanted to have the Pending Changes window show only the pending changes for files in the currently open solution and not all of the other changes in your workspace?

    There's button, called "Filter by solution," that does exactly that.  It's located between the Refresh button and the Workspace selector.

    The button acts like a toggle.  When it's in the "active" state, the Pending Changes window restricts the list of pending changes to those involved in the currently open solution.  If you don't have a solution open, the button is disabled.

     

  • Buck Hodges

    Warehouse troubleshooting guide

    • 0 Comments
    Bryan MacFarlane posted a troubleshooting guide for warehouse problems in the MSDN Team Foundation Forum.  If you are having problems with your warehouse or reports, it's a good resource to try to figure out what's going wrong.
  • Buck Hodges

    Source Control Explorer now shows more information about the state of items

    • 3 Comments

    One of the problems that users encounter when using Source Control Explorer is knowing what state the file or folder is in, particularly if it is shown in gray rather than black text.  In beta 3 refresh and ealier, gray text meant that the file or folder was unmapped, cloaked, deleted, or not downloaded.  There was no way to tell a deleted file from a cloaked file, for instance.  It often left users asking the question, "Why is that file (or folder) gray and how do I change that?"

    Recently, we added more information to what Source Control Explorer shows simply by changing the "Latest" column to say more than yes or no. 

    In the screen shot below, you can now see that I have the latest of the folder Mine (the folder itself, we'd have to go into the folder to see the state of the contents); the folder Misc is cloaked; the folder Old has been deleted; and I do not have the latest version of foo.cs.  If I had added an folder that wasn't mapped to the example below, you'd see "Not Mapped" for that folder.

    By default, viewing deleted files and folders is turned off, in which case I wouldn't see the folder Old.  To have Source Control Explorer display deleted files and folders, go to Tools -> Options -> Source Control -> Visual Studio Team Foundation and check the view deleted items setting.

  • Buck Hodges

    Using VS to get the URI for a Team Project

    • 0 Comments

    Someone asked a question today about getting the URI for a Team Project.  James Manning's Team Project code sample showed how to do it using the API.  However, that was overkill in this case.  Bill Essary pointed out that you can select the Team Project in Team Explorer, right-click on it, and choose Properties (rather than right-click, you could just hit F4).  The Properties window shows the URI as the Url property (yes, apparently no one noticed that).

    The URI you get will look something like the following.  All Team Foundation URI's start with "vstfs:///" that will be tranlated to actual server URL's as needed.

    vstfs:///Classification/TeamProject/7c0d0a50-e31a-4bed-8e48-a99bc95def95

    The URI isn't needed for any normal day-to-day tasks.  Occasionally, you may have the need for it for some advanced admin activity.  TfsSecurity, for example, can accept Team Project URI's for some options.

  • Buck Hodges

    New CTP of Team Foundation is available (NOT supported by go-live)

    • 0 Comments

    Jeff Beehler has just written a post about the newly-released December CTP of TFS.  Jeff describes some of what changed, but probably the most important thing is that it is NOT supported under the go-live license.  There will not be any migration scripts to move to it or from it.

    The reason for that is that this release hasn't been through much formal testing.  Sure, we upgraded our dogfood system with it, so we think it works well enough.  But the goal here was to get a drop out for folks to test out all of the changes we've made, though not in production use.

    If you do try it out and find a bug, or if you find a bug in beta 3, please file it through the MSDN Product Feedback Center.  All bugs filed there get reviewed and assigned to the appropriate dev, as appropriate.  The bugs from PFC are automatically imported into TFS Work Item Tracking in our dogfood system.

  • Buck Hodges

    C# 3.0 features

    • 0 Comments

    I just read Ian Griffiths' post on C# 3.0 and LINQ - Expression Trees (linked from Jomo Fisher's C# 3.0 post, which was linked in John Rivard's Why Visual Studio targets only one version of the .NET Framework, which was in a link from Soma's Multi-targeting of .NET FX in Visual Studio post, which I received in an email notification).  He provides a link to the C# 3.0 spec, which I read through quickly before reading his post.  I hadn't looked at any of this stuff that was evidently unveiled publicly at PDC '05, so this probably isn't news for a lot of people.

    Anyway, reading Ian's blog post tied the whole thing together for me, including the expression trees for query optimization, among other things.  When I was reading through the spec, some of it was pretty apparent, but I see now why each of the features is there given the context of LINQ.  I can only imagine what obtuse code some folks will write with extension methods.

  • Buck Hodges

    Work Item Tracking will use display names for RTM

    • 7 Comments

    In beta 3 (including refresh) and earlier, work items have always been assigned to user names.  For some organizations, that's a real problem, as the user names do not have any relationship to the user's real name.  We have fixed this for RTM.  Brian Harry sent the following email about it, and I thought it was worth sharing (substituting Joe Developer for an actual employee's name).  It's another example of where customer feedback has had a significant impact on the product.

    We went round and round on what to do about this.  For most of the product cycle TFS has used peoples' aliases everywhere.  I don't think we even asked the question very hard about whether or not that was the right thing.  It's what we've always used internally and it seemed obvious that's what TFS would use.
     
    A few months ago we started hearing  significant feedback from customers that this is not workable.  We did a bunch of research and found that many customers have obtuse aliases like nm39756 and that no one in the organization can recognize them.  Many customer say this was a significant adoption blocker for them.  Working together with customers and trying to balance addressing their issue against the cost of changes at this late point in the product cycle, we decided to make a change.  In version control, build and a few other areas we still use users' aliases.  However in work item tracking we use display names.  I expect that in a future version we will unify this to make them consistent.
     
    It is true that display names need not be unique.  This can cause some confusion, however work item tracking isn't the only place in an organization where having multiple people with the same display name can create a problem.  It makes address books hard to use, email, etc.  What we do internally is to qualify duplicate names.  For example, there are multiple Joe Developers at Microsoft.  The one in our organization has the display name "Joe Developer (VSTS)".  This is the "best practice" we will recommend to customers.
     
    We investigated adding support for automatically qualifying display names when we import them from AD (for example by using their alias).  However we decided that the solution would require a while (and customer feedback) to get right and decided not to do it in this version.
     
    The duplicate display names do not create security problems because all security decisions in the system are made based on the user's SID and not any of the human readable strings.  Further, the UI we use to manipulate security uses the Windows UI to full resolve user names or works with aliases (which are unique).

    I hope this helps you understand where things are and what we recommend to customers.

  • Buck Hodges

    How to diff Word documents

    • 11 Comments

    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

    • 8 Comments

    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.

    Description

    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

    • 2 Comments

    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

    • 3 Comments

    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

    • 10 Comments

    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?

Page 18 of 23 (565 items) «1617181920»