Martin Woodward

In this first episode back from the summer break we talk about the features available in TFS Version Control and talk about some of the fundamental concepts that you should understand to make your life easier.  Don't forget to stay tuned all the way to the end when I offer up a brainteaser for everyone and Paul goes crazy and offers a FULL copy of Microsoft Visual Studio 2008 Team Suite to a lucky listener drawn at random who provides a correct answer to radiotfs@gmail.com before the end of August 2008.

If that is not enough for you, Mickey is running a competition over at Team System Rocks where you could win a years MSDN Premium Subscription with Visual Studio Team Suite.

Don't forget that you can subscribe to the show using the RSS Feed in iTunes or Zune. You can also listen to the show direct.

For feedback or suggestions for future shows please contact us at radiotfs@gmail.com or leave a comment over at the Radio TFS web site.

It turns out that the little video I posted yesterday has taken on a bit of a life of it's own.  Last time I checked, it was in the top 10 Science and Technology posts for YouTube in Ireland.  It's funny how it is always the posts that you do more for your own entertainment that take off. 

Anyway, there is no doubting that Brian is a bit of a character, he's already recorded his first TV appearance as a guest on this weeks, "This Week in Channel 9" (to be broadcast soon).  I wish that Nabaztag had an affiliate program as it sounds like I may have sold a few rabbits for them. 

Anyway, if you can't afford your own bunny, then you can have the next best thing for free.  Your very own Brian the Build Bunny Background on the desktop of a computer near you (standard and widescreen versions available).  Click here to chose a image size that suits you.

I'm always keen try new and novel ways to keep in touch with the status of my software projects.  Fortunately, Team Foundation Server provides many ways to do this.  While the Build Wallboard is fun if you have a spare monitor and machine lying around, I wanted to experiment with some inexpensive dedicated devices, and so Brian the Build Bunny was born.

Brian is a Nabaztag smart rabbit.  He reads out details of check-ins and builds.  If a build has failed then his ears go down to show how sad he feels, but if you fix the build his ears will soon pick up again.

I've had Brian for about a year now waiting to do this project, but when I tried it in the past I always found the response times from the rabbit to be too slow.  However earlier this year, the Nabaztag developers updated the code running the rabbits so that they are now using the XMPP (Jabber) protocol to receive updates and the service now seems pretty good.

Brian is now sitting on my desk chattering away and letting me know what is happening in TFS.  If you want to find out more about how he works and see him in action then take a look at the video. If your company blocks YouTube but you have Silverlight installed then you can view a higher quality version of the video courtesy of the Windows Live Streaming service.  I'll go through the code behind Brian in a later post if there is any interest, but it is pretty much a standard TFS event listener that then sends text to the rabbit using the Nabaztag API.

I've just posted the latest installment of Radio TFS.  I'm actually a show behind on editing so expect to see episode 6 up soon.  However, in episode 5 Paul, Mickey and I attempt to answer some of the common questions we hear people ask about Team System including:

• What is Team System?
• Which edition is right for me?
• Why can't I find Team Foundation Server on MSDN?
• What is Team Foundation Server Workgroup Edition?
• Is VSTS 2005 compatible with TFS 2008?
• Why can't I see Team Foundation Server when I install Team Suite?
• What are my options for migrating from my old system(s) to TFS?
• Can I use TFS with VB6, .NET 1.1, Eclipse etc?
• What is a Team Project - how should it be scoped?
• I deleted a file locally, I do a "Get Latest" and TFS doesn't download it - why?

As well as the usual sprinkling of tangents along the way.

Click here for a direct link to this episode.

If you have any questions that you would like answered, or if you have any comments and feedback about the show then please contact us at radiotfs@gmail.com or visit the website at http://radiotfs.com for quick links to subscribe to the feed in iTunes, Zune etc.

At EclipseCon 2008 this morning, we just announced that Teamprise 3.0 has been released!  If you've been wondering why I have been quiet on the blog lately - but also why anything I have been talking about is Team Foundation Build related, then you are about to find out why :-)  First of all, I'd encourage you to go visit the shiny new website at http://www.teamprise.com.  Our marketing team had too much fun putting that together, including getting a real, live, massive Teamprise power button made up and shipped in a huge crate from New York to be photographed and used as the new site/icon image.

The full release notes are available here, but as has been the tradition for the past few Teamprise releases, I thought I would give you a run down of my favourite new features in the 3.0 release.

At a high level, the features in 3.0 can be summarised as:-

• Full Team Foundation Build integration (including ability to execute Ant based builds)
• Check-in policy support
• Recursive folder compare
• Single sign-on (from Microsoft Windows machines)
• "Destroy" command for version control
• Show deleted items and undelete from Source Control Explorer UI
• much much more (see release notes)

While it is not my area, I should also mention that we've taken this opportunity to make our licensing more affordable for smaller teams.  We have been very pleasantly surprised by the number of people buying 1 to 20 licenses at a time.  Originally, Teamprise pricing was skewed to the Enterprise customers (i.e. simple, all inclusive and with steep volume discounts).  So we have done a couple of things to help out the smaller companies:-

• You can now purchase the various components (Teamprise Plug-in for Eclipse, Teamprise Explorer, Teamprise Command Line Client) individually as well as the Teamprise Client Suite which gives you the lot.
• We have lowered the initial prices for a single seat, meaning that people buying one or two licenses can now get the same discounts that used to only be available to folks purchasing 100.

If you have any licensing issues / queries then feel free to contact me, or you can talk to the sales team direct at sales@teamprise.com.  Anyway - back to the part of this release that I do know about - the technology. 

The first feature I want to talk about is one that I had no involvement with.  It's one of those features that many people will not notice because it just works but anyone who has done any Java to .NET web service interop work will instantly recognise as being a little bit clever.

Single Sign-On

The initial log-in screen has undergone a big overhaul.  On Windows machines you are given the option to use "default credentials", i.e. the username and password that you are logged onto windows with.  It obviously doesn't know your password, but does some JNI magic to get the native Windows API's to handle the authentication logic with Team Foundation Server.  While you are also on the login screen, you may notice the Profile feature.  This is an area that many people probably won't use, but we added for our power users and for ourselves.  Basically, the profiles feature allows you to store sets of servers/credentials that you commonly use to connect to Team Foundation Server and then you can bring up the details using a simple drop down.  Makes it much easier to switch between your production TFS instance and your CodePlex project for example - or switch credentials if you are a TFS administrator.

Check-in Policy Support

In Visual Studio, check-in policies are implemented as a .NET assembly runs every time a policy is evaluated or configured.  The policy also has full access to the .NET API's, the Visual Studio API's as well as anything it might want to pinvoke out to on the Win32 API side.  As you can imagine, this presented us some problems when we wanted to have check-in policies that ran the same in Eclipse on Windows Vista as Teamprise Explorer on the Mac or Aptana on Ubuntu - therefore we have had to develop a parallel Teamprise check-in policy framework.

As we were doing this, we took the opportunity to learn from some of the feedback folks have been having with the Visual Studio check-in policies.  While our framework and SDK will look very familiar to anyone that has developed a custom check-in policy for Visual Studio, you will notice some differences.

Firstly, we supply different policies out of the box.  The vast majority of custom check-in polices that people deploy are things like "Check for Comments" etc, so we just shipped the common ones our customers wanted to prevent them from having to write their own.

Secondly, we make use of the Eclipse plug-in framework to implement our policies as extension points.  This means that they are easy to deploy (using the Eclipse update site mechanisms built in to the IDE).  We have also separated the configuration (stored as a blob of XML data in our framework) from the implementation - represented by the plug-in deployed.  The again makes it easier to deploy, especially when it comes to version 2 of a policy...

Thirdly, all of our policies can be scoped by the path in version control to which they correspond - you are not limited to per Team Project scoping and you do not have to wrap your policies in a custom policy to get more detailed scoping like you do with the current Visual Studio framework.

Team Foundation Build Integration

Anyone that has been following this blog for a while, or who attended the Team Build talk I did at TechEd with Brian Randell, will notice that I have been increasingly involved in the inner workings of Team Foundation Build.  Now you can see the fruits of that labour.

In Teamprise we now have full integration with the shiny new build functionality in TFS 2008 as well as support for TFS 2005.  Backwards compatibility with the TFS 2005 server is very similar to if you were using a Visual Studio 2008 client, accept that ours is slightly more backwards compatible (you can create new builds on a TFS 2005 server as well as manage build qualities etc).  However it is with TFS 2008 that you get to see the majority of the features.  I could go on about this aspect all day as their are so small things that I am proud of, but at a high level you can:

• View existing build definitions
• Manage builds in Build Explorer
• Queue new builds
• View build report
• Edit Build Quality
• Delete build
• Manage Build Qualities
• Open Drop Folder
• New/Edit Build Definition

• Edit Retention Policies
• Keep Build
• Set Queue Priority
• Postpone Build
• Stop/Cancel Build
• Delete Build Definition

One of the smaller features I will call out is that from the build definition in the Team Explorer, you can right click and do a "View Build Configuration" that will open the Source Control Explorer at the place in which the TFSBuild.proj file is stored so that you can check it out and edit it.  A feature that I added solely for my own sanity during dogfooding :-). 

All this would be fairly academic, if you didn't have some way to do a cross-platform build using Team Foundation Build.  In the current release, we provide a the Teamprise Extensions for Team Foundation Build which basically Ant enables the Team Foundation build server.  The Teamprise extensions are a set of MSBuild targets that insert the Ant build process into the standard Team Build mechanism as well as a custom MSBuild We hope to extend this to support in the near future to some of the other common build/test tool-chains in the cross-platform world.  However, the Ant integration case will help a lot number of people out there.

Best yet, the Teamprise Extensions for Team Foundation Build are available free of charge for everyone - wether or not you are a Teamprise customer.  Also, if you want to see how they work and customize them to meet your own non-standard build system then the source is available under the permissive open source Microsoft Public License (MS-PL).

I would personally like to thank the Team Foundation Build Team (especially Buck Hodges and Aaron Hallberg) who have been incredibly helpful through the development of the build functionality in Teamprise 3.0 while they were also busy working on TFS 2008. 

Hopefully that gives you a quick flavour of Teamprise 3.0 and where we are going with this release.  If you head over to the new site now and take a look at the many improvements we've made, we'd love to hear what you think.

Paul Hacker, Mickey Gousset and I have recently started a Team System related podcast called Radio TFS.

While it is not going to win any awards any time soon, we've been having a lot of fun so we are going to continue to try and get one or two episodes out a month. If you have 40 or so minutes to kill, then feel free to take a listen and subscribe.

If you have any suggestions for topic or any questions about Team System that you would like answered then please drop us a line at radiotfs@gmail.com or visit the website at http://www.radiotfs.com.

I connect to the central Teamprise TFS instance over a VPN connection to the head office in Champaign, IL.  It is a direct distance of nearly 4,000 miles - but probably much longer depending what route my packets take - on a good day typical ping times for me are ~150ms, but bandwidth is also a major issue.  On my current ADSL line (that is booked in for upgrade before the end of the month) I get 140 kbs upstream and about 400 kbs downstream - on a good day.  On a bad day, it can be much worse.  Last year someone decided to start shooting at bits of fibre optic cable in Ohio and that really messed up my day.

In many ways, the fact that Teamprise has a couple of the core development team working remotely over the VPN is good for Teamprise the product because we certainly complain if we encounter any performance issues during dogfooding - issues that the folks in the office with a gigabit connection to the TFS server might not feel as strong about :-)

TFS mostly works great for me over my VPN connection.  The TFS team did a lot of work to optimise TFS traffic for WAN environments, such as use of standard web based protocols for transport, the heavy use of compression, minimization of the SOAP payload, keeping connections cached and not to forget things like inventing the TFS Proxy Server - you can certainly tell that TFS was designed with this type of environment in mind.  (I'm sure it helps that the majority of the TFS team are based in Raleigh, NC while their dogfood TFS instance is based in Redmond, WA ;-) ).   The only times where I have issues are on the rare occasion when Windows File Shares are used or the client needs to query Active Directory information.

Obviously - Windows file shares are an issue for Teamprise in general (with around 50% of the team using non-Windows systems as their primary machine).  But most modern operating systems can talk to CIFS based file systems pretty well.  The issue for me is that Windows file shares suck over a high-latency, low bandwidth connection.  This was one of the reasons VSS performed so badly over a WAN.  Thankfully there are only a couple of main areas in Team System and TFS where Windows file sharing is currently used:-

1. Publishing of test results from the client
2. Accessing the TFS build drop location (and most annoyingly, the build log file).

Note, it because of these types of issues (and the Active Directory releated ones) that I always recommend people connecting into TFS remotely use a VPN if they want access to the full functionality.  While the Windows file sharing bits may perform really badly - at least they will work over a VPN.  Try getting file sharing to work securely between firewalls if TFS is exposed on the internet and a VPN is not used...

In a follow up post, I'm going to be talking about how to modify your builds to make them easier to work with over a WAN / VPN.  Despite these minor niggles (which don't come up very often), if you are considering using TFS for use over a VPN or Wide Area Network then I would certainly recommend it.

Update: With Teamprise 3.0 we included this work into the freely downloadable Teamprise Extensions for Team Build. The source is also provided under the MS-PL if you are interested. You should definately look at the new version as it contains some fixes and additional features based on feedback during beta testing.

Original Post:

With the recent release of Microsoft Visual Studio 2008 Team Foundation Server we are seeing more and more people looking to use the build capabilities of TFS (often referred to as "Team Build") to manage their Java based builds as well as their .NET ones.  We have an MSBuild task available internally that we use to trigger Ant based builds and report the progress back into TFS, and I wanted to share this with a wider audience to get some feeedback.  This task is heavily influenced by Aaron Hallberg's Team Build DevEnv task which I encourage you to go look at if you are interested in getting other build systems integration with Team Build.

You can download an early version of the Ant task from here - (TeampriseBuildExtensions 1.1MB).  There are two versions of the task included in the zip file - one for TFS2005 and one for TFS2008.  Additionally there is a draft set of instructions included on how to get this working today.  We hope to make the process much easier with future releases of Teamprise.

The Ant task works by calling Java to run Ant. The task first parses the Ant file to locate the name of the project and the description. It then calls Ant and the resulting output from Ant is then parsed by the task to look for key information (such as javac and junit tasks) as well as to pass the results into the MSBuild log. Options which are normally available via ant launching script are available as additional attributes to the Ant task.

Example Usage

<Ant TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
  BuildFile="$(SolutionRoot)\java\HelloWorld\build.xml" 
  BuildUri="$(BuildUri)" 
  AntHome="$(ANT_HOME)" 
  JavaHome="$(JAVA_HOME)" 
  Flavor="%(ConfigurationToBuild.FlavorToBuild)" 
  Platform="%(ConfigurationToBuild.PlatformToBuild)"   
  Properties="BinariesRoot=$(BinariesRoot);BuildNumber=$(BuildNumber);SourceGetVersion=$(SourceGetVersion)" />

Task Reference

The following is a complete list of all the attributes supported by the task, note that many of them are best left to the default values unless a different behavior is explicitly required. Items that are in bold are the ones that are frequently used.

As part of the next version of Teamprise we will be providing integration with Team Build in the UI (i.e. inside Eclipse based IDE's or in the stand-alone Teamprise Explorer client).  More on those build capabilities soon - but hopefully you can see that with the ability to run Ant based builds from Team Build and the ability to control/monitor from Eclipse you will have a nice build system that is fully integrated with TFS.

If you find this task useful, then be sure to drop me a line with any feedback you might have.  We have not yet decided how to make the source of this task available, either as an open source project of it's own or as part of a larger community of MSBuild tasks.  There are pro's and con's to both.  In the meantime, if anybody would like the source code then drop me a line.

If you are customizing a team build, then there are only two things you need to know to get you started.  The rest you can (mostly) figure out from there.

1. Your build is defined in a file called TFSBuild.proj for your particular Team Build Type.  You probably figured that bit out already.  The first thing you need to know is that the TFSBuild.proj file inherits most of its logic from a file called Microsoft.TeamFoundation.Build.targets which lives in
   %ProgramFiles%\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets.
   If you open this file in Notepad you can see that it is exceptionally well commented.  There is no smoke and mirrors with Team Build, if it happens at all then it triggered by this file. Note that you should never edit the Microsoft.TeamFoundation.Build.targets file.  In Team Build 2008 there are so many hook points provided for you to insert your own logic into the build that you should never need to.  Microsoft goes to some rather extreme lengths to ensure backwards compatibility with this file (i.e. a TFSBuild.proj file written with the TFS2005 targets file in mind will work just great with the 2008 targets file).  If you modify the targets file, not only are you setting your self up for deployment nightmares but you servicing nightmares as well if you attempt to upgrade to later version or even possibly service packs - don't say I didn't tell you ;-)
2. If you get a bit lost in reading the targets file - the MSDN help for build customizations is pretty good.  The best starting point is the page "Understanding Team Foundation Build Configuration Files" - however the pages that this links to that I refer to constantly are Customizable Team Foundation Build Targets and Customizable Team Foundation Build Properties.  That said - most of the comments in those MSDN help pages are actually in the targets file itself - just sometimes the property or task you are after is easier to find in the MSDN help.

If (like me) you are using the tf.exe command line to access your Team Foundation Server via a Version Control Proxy from a remote office, then the following tip is extremely useful - much more so than my previous registry hack. 

There is currently no option with the Microsoft command line to pass a version control proxy server in to TF.exe.  It will pick one up if you have one set in the registry if you have used the Team Explorer GUI - but that isn't great for scripted scenarios.  James Manning recently pointed me in the direction of an undocumented environment variable called TFSPROXY.  If set, the TFS client will use that setting to proxy your requests.  Therefore the following will call tf.exe passing a proxy server to use in your connection:-

@echo off
setlocal
set TFSPROXY=http://your_proxy_server:8081
tf %*
endlocal

I saved this in a batch file called "tfvp.cmd" (for "tf via proxy"), therefore if I want to call tf via my proxy and I'm in a shell that doesn't have the environment variable set I can call my script.

The only command that this really useful for is when doing a tfs get command, as only the download is sent via the version control proxy server, the majority of requests go direct to the main Team Foundation Server application tier that you are connected to.

By the way, if you are using the Teamprise command line client then you can use the /proxy:http://your_proxy_server:8081 argument to specify a proxy server to use for the connection, I've just logged a bug so that we will also accept this undocumented environment variable, but we'll make it so that passing one explicitly will override any picked up from the environment variable.

One of the questions that came up from one of our users was "how do I delete the files from my local file system - and tell Team Foundation Server that I have done this".

The first thing you might try is to just delete them locally.  However, Team Foundation Server (TFS) uses your workspace to keep track of what files you have downloaded and what version you have of them.  The reason it does this is so that it can maintain your files without a costly (both in terms of network and CPU processing) sync step.  With TFS, when you say "Get latest", you only get the latest version of files that have changed since you last got them.  Nothing is downloaded that you don't need (thereby saving you network traffic).  A really neat thing about TFS is that if you delete a file on the server and check that delete in, then when somebody does a "Get Latest", the file is deleted on their local system as well - very nice.  Moves and renames also exhibit this behavior - really useful for keeping the local file system in sync with the servers. 

But, if you have deleted a file locally (using Windows Explorer for example) then do a "Get Latest" the file is not downloaded - because the server thinks you already have it.  You can easily download the file by going to "Get Specific Version..." and selecting the "Force get" option - which will download all files, regardless of if the server things you have them or not.

The question I was asked was how to tell the server you have removed the file from your system, without deleting it from the server.  In the end, it took me a while to figure out the answer (and the help of Buck Hodges)

The answer is, if you do a "Get Specific Version..." on the files, and select Changeset 1, the files will be deleted locally and the server will know this.  The color of the file in the Source Control explorer will go from black to gray and will have the phrase "Not downloaded" in the latest column.

Changeset 1 is a special changeset on your Team Foundation Server instance.  It was created as part of the setup routine and only contains one thing - the root node ($/) in your source control tree.  If you do a get for changeset 1 on any actual files then they will not exist at that point in time on the system so will be deleted locally and the server will know this.

Anyway, I thought this worthy of a TFS Tip post.  Not only because it highlights how to do something that is non-obvious, but also because once you understand how it works, you will understand a large part of what you need to know about Team Foundation Server Source Control.

Team Foundation Server source control has a great feature called Shelving.  Shelving lets you set store a batch of pending changes onto the server and optionally remove them from your local workspace.  It comes in really handy for the times when you want to backup your code and store it on the server but don't want to commit it to source control.  I also sometimes use it when I would like a remote colleague to take a look at some code I have written before I commit it into the code base.  For more information about Shelving, see the MSDN documentation.  A Shelveset is identified by developer and the name the developer gave it when shelving.

One of the features of shelving (and how it differs from working in a private developer branch) is that a Shelveset is in itself not versioned.  If the same developer saves a Shelveset with the same name, then it will overwrite the previous Shelveset.  This comes in really handy when you have a Shelveset that you commonly use for one thing - for example, I have a Shelveset that I normally call "Work In Progress" (actually, I normally call it "wip" because I am lazy when it comes to typing, but you get the idea).  If I need to stop work, but I haven't been able to get to a point where I can check-in the code, then I shelve the pending changes and call the Shelveset "Work In Progress".  That way, I only have one of these and I know the purpose of it.

However, most of the time when you shelve, it is a temporary thing.  You create a Shelveset and then you unshelve it - and then you no longer want it.  The old shelvesets will sit on your shelf gathering dust until you tidy them up by deleting them.  The unshelve dialog has a "Delete" button that you can use to delete a particular shelveset.

Additionally, if you press "Details", then you get to see more information about the shelveset in question - but you also get a couple of other options controlling the behavior that occurs while the unshelve is being performed:-

If you un-check the "Preserve shelveset on server" check-box then your shelveset will be automatically deleted after you successfully unshelve it - which is a quite handy (if slightly hidden) feature.

It's good practice to delete the shelvesets when you no longer need them.  Not only will it get rid of clutter for you, it will also help when another person is trying to unshelve something that you have placed there for them.

So, this isn't exactly original material - but I was having a chat with somebody today who I consider very knowledgeable about Visual Studio Team System and they were not aware of these so hopefully re-posting some will help more people discover them.  Strictly speaking, as all of these have been mentioned somewhere before the word "Secret" isn't correct - however it gave an otherwise very dull post a certain bit of excitement which kept you reading this far so forgive me.  The usual Caveats about messing with the registry apply, also the default settings are generally more logical to new users so use with caution.  Most of these tips apply to HKEY_LOCAL_MACHINE as well as HKEY_CURRENT_USER - I normally set them as a user preference so as not to confuse anyone else that should happen to use my machine.

Hack #1 - Stopping Team Explorer from connecting on Visual Studio 2005 Start-up

Add a DWORD value called "AutoLoadServer" under HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation.  Zero means do not reconnect automatically.

I first read about this setting over at Tim Noonan's blog.  This can be very handy if, like me, you frequently change TFS servers.  I jump between the work TFS instance, CodePlex and a test or VPC versions of TFS.  I know which server I want to connect to when starting VS 2005, and frequently it is not the one I connected to last time.  Adding the following setting means that I have to manually pick the server I want to connect to from the "Add Existing Project..." button.

Hack #2 - Don't get Missing Files

Add a DWORD value called DisableGetMissingFiles under HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation\SourceControl.  Any value other than zero will disable getting files from the server automatically.

Another Tim Noonan special.  This setting determines if files missing from the solution or project are automatically downloaded.  I normally switch this off and so get the files only when I say "Get Latest" on a particular solution or project, this is especially useful when you are not always connected.

Hack #3 - Bypass proxy server

Add a String value called BypassProxyOnLocal under HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation\RequestSettings.  A value of "true" will bypass.

This one from the legendry Buck Hodges.  In some network configurations, the Microsoft Team Foundation Server client will connect to your Team Foundation Server via a web proxy server.  This should be avoided as it slows everything down and the NTLM authentication used by TFS doesn't play well with some proxy configurations.  I've seen this pop up as a problem with environments that use a proxy.pac file to control proxy access rather than hard-coding the entries in the Internet Options, LAN Settings (or for folks that don't have Bypass local set up).  You should probably only use this setting if you know you are having this problem (often diagnosed by an intermittent failure of Team Explorer to connect but easily checked using a network sniffing tool such as Ethereal).

Hack #4 - TFS Version Control Proxy Settings

See HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation\SourceControl\Proxy.  A String value called Url containing the proxy address and a String value called Enabled set to true will enable the source control proxy.

The easier way to enter values for what machine to use as a TFS Version Control Proxy is to go to into Visual Studio with Team Explorer installed and select Options, Source Control, Tools, Options, Source Control, Visual Studio Team Foundation Server, Proxy Settings.  However, if you are running a tf.exe script or TFS .NET API code as part of a service and you want the code to go via a proxy then the HKEY_LOCAL_MACHINE version of this setting is very useful for setting a default.

Hack #5 - Configuring the TreeDiff Power Toy

See Brian Harry's excellent post about some registry tweaks for Configuring the TreeDiff Power Toy to your whim.

Recently, I've had a surge of emails asking various questions about Team Foundation Server and how to do certain things.  While I always (eventually) respond, it can sometimes take me a while.  If you have questions about Team Foundation Server then the best place to go is the MSDN forums.  These forums are monitored by the VSTS team as well as by the Team System MVP's and other folks who know stuff about the product.  Unlike a lot of newsgroups, these forums are actually a very welcoming and friendly place to ask questions.  I personally hang out on the following forums:-

• Team Foundation Server - General
• Team Foundation Server - Setup
• Team Foundation Server - Version Control
• Team Foundation Server - Work Item Tracking
• Team Foundation Server - Administration
• Team Foundation Server - Build Automation
• Team Foundation Server - Process Templates
• Team Foundation Server - Reporting
• Visual Studio Team System - General
• Visual Studio Team System - Developers

As well as the official MSDN forums, you can also try one of the community ones.  These don't tend to get the traffic from Team folks but are still good resources.  It's also a good place to ask questions that you might not want to ask on a Microsoft resource (such as how does TFS stack up against Product B) and get an answer from somebody who is not paid by Microsoft.

• Team System Rocks (excellent community resource site)
• TeamFoundationServer.org (a new UK based resource)

At Teamprise we also have our own forum and knowledge base that are worth checking out if the question is related to use of Team Foundation Server from Java or on the Unix / Mac / Linux platforms.

Before you ask the question, it is probably worth checking the MSDN documentation first or using your favorite search engine, but don't worry about asking if you can't find your answer - the folks on these forums are always happy to point you to the best resource.

You never know, if you ask a question on these forums then you might still get me answering it if you are unlucky enough.  By asking the question in a public forum you are doing a service for the next person that comes down the line with the same problem as they'll be able to see somebody else with the same issue and (hopefully) the answer.

UPDATE:  Brian Harry has posted a new utility to help you determine the trial expiration dates on your server.  View Brian's post for more details.

Like a lot of early adopters, we installed the Team Foundation Server 180–day trial edition so that we could use is right away while we were waiting for our TFS license key.

Anyway, if you want to know what the installation date of your TFS server is then the easiest way is to type the following command in a Visual Studio 2005 command prompt:-

tf changeset 1 /server:http://servername:8080 /noprompt

Where servername is your TFS instance.  I get the following result:-

Changeset: 1
User: tfssetup
Date: 20 February 2006 19:57:54
Comment:
Items:
  add $/

During the installation, Team Foundation Server creates the root branch of the source tree and this is the first changeset on your system.  If you add 180 days to this date then you get when your trial will expire.

Now, in my case it is even more confusing.  I installed the Release Candidate of TFS on February 20th, and then upgraded to the 180–day trial edition of TFS on March 21st.  A fact that I can tell from my installation log file located on the Team Foundation Server in the following directory:-

C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Microsoft Visual Studio 2005 Team Foundation Server - ENU\Logs

Which date will be used for the expiry of my server?  Well at the moment I have no idea, so I am assuming the earlier of these dates will be used just in case…

However, for most people who went straight to the 180–day trial, the command at the top of this post will give them the date of initial install.

This tip is a follow up from my rather less helpful post “Don’t Do That” where I discussed the “Inherit security settings” option in the security settings tab for the Source Control Explorer when talking to Team Foundation Server.  The issue with this check-box is that if you un-tick it then all the settings for every group on that folder are removed meaning that you have to go through every group and make sure that they have the correct permissions before you press the OK button.  Even if you are a project administrator and you un-tick this box and press OK without giving project administrators rights to the folder or file you will not be able to go back and adjust the permissions.

However, I have found a work around should you be left stranded in this way.  If you log in to TFS with the credentials of somebody who is a local administrator on the server then you will be able to view the folder and reset the security permissions.  The easiest way to do this is to log on locally to your TFS application tier machine as the TFSSetup user and use the source control explorer on that machine to rectify the problem.  Obviously it is not ideal but at least you are not totally stranded.

Rather embarrassingly, I found this work-around totally by accident while up on stage presenting my recent talk “Top Ten Tips for Team Foundation Server”.  My finale was going to be trashing my TFS installation by un-ticking this box and pressing OK without giving the Project Administrators the appropriate rights – however it wasn’t as dramatic as I’d planned.  Turns out that this was because I was also the TFSSetup user on the VPC I was using as the TFS server.  At least next time I can make it dramatic and then show folks how to fix it!

If you are going to be doing more than the basic check-in / check-out options then it pays to get to know the command line client – tf.  The command line client is actually the most flexible and powerful client to Team Foundation Version Control.

For more information, consult the MSDN help documentation.  Teamprise users will be glad to hear that a large percentage of the commands are implemented in V1.0 of our command line client meaning that you can do these actions from a Mac or Unix box as well (install instructions are posted in the Knowledge Base).  If you are running on Windows then you are probably better off sticking to Microsoft’s command line client that gets installed as part of the Team Foundation Server client installation (and accessible via a Visual Studio 2005 command shell).

For example, to show all the check-outs by everyone on a path in the repository:-

  tf status /server:http://yourservernamehere:8080 /user:* /recursive $/TeamProject/

For more examples, see an excellent post from James Manning or some of my previous posts:-

• Hatteras Command Line Tips (from back when tf.exe was called h.exe which saved a keypress :-), however the documentation was no where near as good as it is now )
• Unlocking files in VSTS

The command line client is also excellent for scripting purposes (our automated build system relies heavily on it).  I urge you to spend a few moments with a strong cup of coffee, the help documentation and just have a play around.  Once you realise what commands are available then you’ll know what’s possible if you come across a situation in the future where you reach limitations in the UI.

I don’t know about you, but I love associating my check-ins with work items using the Pending Changes view, it makes it so easy to maintain requirements traceability and helps me feel less guilty as I’m doing one more thing that I should have been doing for years. 

The only problem with the default definitions for Bug and Task are that if you select the item then by default the “Resolve” check-in action is selected.  This is annoying for me as it the action I want to take in probably about 5% of check-ins.  95% of the time I just want to associate and 90% of the time I forgot that I have to change the default setting and end up going back to the work item and re-activating it.

The “Resolve” option is displayed when a state transition in the work item’s workflow is defined as having an action defined for check-in.  Below is the transition section from the MSF Agile Bug:-

If you remove the actions section from the transition from Active to Resolved transition then the only check-in action available will be “Associate”.  Admittedly, this means that I have to edit the work item after finishing checking in files to move it from Active to Resolved – but I find this works better for me.  I usually leave a little comment in the history as I change the state to say (at a high level) what I did and in the case of bugs any help I need to give to help the fix be verified by the test verification team.

When you connect to a Team Foundation Server, the Microsoft client API attempts to connect with your current credentials that the process is running with under Windows.  If you are on a different domain than your TFS server or the user that you are logged in with does not have access, then you will be prompted to enter your login credentials using the standard login dialog box that you will be familiar with from Internet Explorer.

However, what if you pass credentials and now you would like to pass in a different set.  In Teamprise it is easy enough because we have to ask you them every time you connect.  With the Microsoft API your credentials are cached in the standard windows store.

To access this store (and remove your cached credentials allowing you to re-authenticate as a different user) then go to Control Panel, User Accounts, Advanced Tab, Manage Passwords.  You should then locate your TFS Server instance and select Remove.

I thought I’d try and post some quick Top Tips for Team Foundation Server – in no particular order apart from as I think of them.  Today, this came up in the forums so I thought I’d elaborate.

WIQL (pronounced Wickle), stands for Work Item Query Language and is what is used when talking to the work item store in Team Foundation Server.  It has a SQL like construct and is used to pass queries to the server.  Visual Studio 2005 comes with a Query Editor that generate WIQL.  While the query editor is straightforward, it is pretty powerful and allows you to do most things.

However, the query editor is region sensitive which sometimes causes confusion.  Take the following example where I am using an “IN” statement to list a set of values for the work item status:-

Note that the values are separated by commas.  Those of you from a SQL background find this very sensible, but what the query editor is actually doing is taking the list of values and converting them into the following WIQL statement:-

(A top sub-tip is that it is possible to save WIQL files from Visual Studio by editing the query then selecting File, Save Query As.. and then select file.  To run a saved query from the file system double click the *.wiq file from explorer)

The comma separator used by the query editor is actually being picked up from the “List separator” of your regional settings (shown below) (Start, Control Panel, Regional Settings, Customize…)

If you are in one of the many regions of the world that use a different list separator then you have to use that in the Visual Studio 2005 Query Editor.  For example, if I change my list separator to be a semi-colon and then re-edit the query in the Visual Studio 2005 Query Editor I get the following:-

This behaviour has some interesting side effects.  Remember when I said that the Visual Studio 2005 Query Editor “allows you to do most things”.  Well, one small problem is forcing the editor to take a character to say that you want the following to be treated as a string.  For example, if you have a comma in the text value you are trying to use in an “IN” statement then you are hosed because the query editor assumes that this is a new value in your list.  For example, if you try the following:

This actually gets translated by the query editor as the following:

As you can tell, it parses on the commas first, which is not want you wanted at all.  If you manually type in the WIQL correctly as IN (‘Woodward, Martin’, ‘Sell, Clark’) then the query editor will display this as Woodward, Martin, Sell, Clark – which in turn gets treated as IN (‘Woodward’,’Martin’,’Sell’,’Clark’) when the WIQL is generated by the editor. 

Hey ho – Clark Sell has a post about changing the regional settings to enable to to query assigned to names but be warned it may have nasty side effects in other programs on your machine.

Hmm.  When I thought about posting a TFS Tip a day for the next couple of weeks I didn’t intend them to be this long.  Expect the next one to be more concise…

Now playing: Carl Franklin - Avalon, AJAX, Vista, and more with Tim Huckaby