How do I find stuff in TFS 2010?


The other day I was coaching a colleague and I got the excellent question about how to find stuff in TFS 2010. So I explained to my colleague about some of the different ways you can find stuff and realized that this would be an excellent and hopefully informative post for me and others.

Scenario 1: you know the Id of the Work Item you’re looking for

If you’ve ever worked with TFS for a while you’ll (hopefully) start to memorize (unconsciously) the unique Id’s for the tasks, bugs, user stories, test cases e.t.c. that you work with. If this is your case then you have 3 very fast ways of accessing these Work Items fast.

Inside Visual Studio

  1. Right-click the Work Items node and choose Go to Work Itemimage
  2. …enter an Id
  3. and wooops there it is.

Or if mouse clicking isn’t your way of life add a keyboard shortcut that does the same thing as shown below:

Inside the Team Portal and Team Web Access

On your Team Project Portal you should have a textbox that will do the same as the Go to Work Item above inside Visual Studio. It will look something like this:


The exact same textbox is present in Team Web Access and look like this:


Scenario 2: you don’t know the Id of the Work Item you’re looking for

Let’s pretend that you don’t remember your Id’s or perhaps you’re a new team member on an ongoing Team Project, what do you do then?

Well you could go through all of the work items and search for the ones you’re really interested in Ler or you could search for Work Items. This is in my experience a somewhat unknown functionality that I would really love to have inside Visual Studio but if you go your Team Web Access you can actually search for words in title or description fields as shown below:


Scenario 3: you need to filter out an massive amount of Work Items

The best way to find, filter and structure you Work Items is to create good Team Queries, and I will not go into details how you accomplish this but I will give you a great tip.

  1. Take an existing Work Item Query and choose Edit Query
  2. Change it the way you want it
  3. Save it as your own Work Item Query or as a new Team Query (use folders to create even better structure)

Another great tip is to open your Work Item query in Excel and then use the power of Excel to filter stuff.


Scenario 4: use the power of search in SharePoint

The best way to find information in SharePoint items and in documents on your Team Portal is to use the awesome powers of SharePoint Search. Here is a sheet explaining some of the cool features in the box.



Stuck on “Cannot create unknown type {clr-namespace:” in TFS Build?


A couple of days ago I was upgrading some of my clients MSBuild tasks to WorkFlow Activities following the “Rewrite MSBuild task as a Workflow Activity” option in the guidelines from this excellent post by William Bartholomew.

I stumbled upon a custom Assembly Versioning MSBuild task and I took a moment of thought to see what I could do to improve this MSBuild task. I read this great post by Mike Fourie’s and yet another great post by John Robbins that I really encourage anyone doing custom versioning in TFS 2010 to read.

I decided to follow some of the posts recommendations and decided that for the purposes of my client I would not need to convert this (former) MSBuild task into a coded CodeActivity because a designed activity would be more then enough.

Anyway a simplified version of the clients workflow activity looked something like this:

With some input arguments that looked like this:


Everything is pretty straightforward if you’re custom to TFS Build and Windows Workflow Foundation except for the Activites in the Then/Else sections. In the Then/Else sections I’m using the AssemblyInfo Activity from Community TFS Build Extension here.


So I check-in my custom assembly and make sure that the controller is pointing to the folder in the source control tree that contains my custom assemblies.

I then added my new Activity to the build process template and ran my first build against that build process template…BOOOOOM! Got this message: TF215097: An error occurred while initializing a build for build definition \Tailspin Toys\HugoHaggmark: Cannot create unknown type ‘{clr-namespace:HugoHaggmark.TfsBuild.Activities}Example’.



Are you in the same situation as me? Don’t despair a simple solution is close. Ler

  1. Firstly open up build process template as XML.
  2. Find the reference to your Custom Activity in the XML (probably in the top section of the XML), looks something like this:
    xmlns:local=”clr-namespace:<YourNameSpace>” or in my case I had this:
  3. Add ;assembly=<Name of your assembly> to that reference so in my case the end result looked like this:
  4. Create a partial class right next to your Custom Activity and add the BuildActivity attribute like shown below:
  5. Check In, rebuild and redeploy assemblies to the custom assemblies folder.
  6. Run the build and voila! The build error is gone!



Yet another post about Team Build and the 260+ char limit

So this is definitely not a new topic and there has been lots of post about it. But I’d like to make sure that you don’t find yourself in the situation where you receive the following error message:

”The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.”

As many already have stated this is not a limit in Team Build but a Windows limit, you can read more about that here.

Even though many devs out there are brutally aware of this hard limit I tend to see the same mistakes appear at customers over and over again.

Lets start out with some basics:

  • Don’t create source control folder hierarchies that mimic your namespace naming or any other convention. That leads to deep hierarchies that will get you closer to the 260+ limit.
  • Instead try to keep your source control hierarchy as flat as possible, use the solution folders feature in Visual Studio to represent your hierarchy instead.

    See how the Source and Tests hierarchy are used as Solution Folders instead in Visual Studio without creating any extra folder level in source control:

  • Keep your workspace folder mappings short and consistent like “C:\ws\”
  • Keep your namespaces short and sweet and remember that you don’t need to name your solution/project folders the same as your namespace (although I know it simplifies the daily work a lot Blinkar)

And here are some advanced strategies:

  • Use $(BuildDefinitionId) instead of $(BuildDefinitionPath) when you configure your build agents.
    The picture below shows the output in folder structures between these two approaches using the same build definition but different agent settings. The pictures are taken from a TFS 2010 installation for TFS 2008 there is no $(BuildAgentId) folder.
  • In TFS 2008 shorten the “SourcesSubdirectory”, “BinariesSubdirectory” and “TestResultsSubdirectory” configuration in the TfsBuildService.exe.config.
  • In TFS 2010 shorten the assignment in the string for the “Initialize Sources Directory”, “Initialize Binaries Directory” and “Initialize TestResults Directory” in your DefaultTemplate.xaml as the picture shows:
  • In TFS 2010 if you’re using the UpgradeTemplate.xaml you can substitute the name for the directories in the Advanced section like the picture shows:
  • Create a custom Check-In policy that prevents users from checking in structures in source control that are longer then some number set by your administrator. Read more about it here.

This should prevent you from hitting the 260+ hard limit for a while but It’s no silver bullet unfortunately so I hope that a more complete solution will rise soon.