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.



Building and Unit Testing .Net 4.0 with Team Build 2008, the correct order

I’ve been helping my customer setting up .Net 4.0 build servers lately as you may have read in my previous post. In the previous post, I listed my challenges getting .Net 4 assemblies to build and unit test with Team Build 2008 so I thought It would be time to share the correct order to get the stuff working!

  1. Install Visual Studio 2010 Premium
  2. Install Visual Studio Team System 2008 Development Edition
  3. Install Visual Studio Team System 2008 Service Pack 1
  4. Install Team Build 2008
  5. Install Team Build Service Pack 1
  6. Configured Team Build 2008 to use MSBuild 4.0 instead of MSBuild 3.5. To do this edit %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\TFSBuildService.exe.config and set the MSBuildPath property to C:\Windows\Microsoft.NET\Framework\v4.0.21006\

That should do it! And if you install your build server in that order you won’t get the following error:

  • MSBUILD : warning : Visual Studio Team System for Software Testers or Visual Studio Team System for Software Developers is required to run tests as part of a Team Build
  • And you won’t replace the Microsoft.TeamFoundation.Build.targets with an incorrect workspace pattern:
    TFS Build 2008:
    After VS 2010 installation:

Hope this summarizes how to install a build server that builds and unit tests .Net 4.0 applications with Team Build 2008.



How come the add button in Associated Automation isn’t visible in Microsoft Test Manager?

This year is off to a great start with fantastic first week and an even better last day of that week working with my fellow Avega Coach, Marcus Hammarberg .

Our work yesterday is clearly summarized by Marcus in this post and I think Marcus has made some real groundbreaking thoughts on SpecFlow together with TFS and Visual Studio and I’m very glad to have helped out some parts. A shout out goes to Håkan Forss as he gave both of us some valuable feedback too.

So what’s this post about you might ask? Well during our work we stumbled onto a gotcha with the way Test Manager and associated automation works.

As you can see in the picture below I’ve created a Test Case that some tester later gets to run.


Suppose the tester runs this Test Case and finds a bug. Now we want to assign this bug to a developer who fixes the bug and associates a test with the test case in such way that the test case gets automated.

So we change the automation status to Planned as you can see in the picture below:



As you can see the tester can’t set Automation Status in Test Manager to Automated because that state is missing from the list and if we zoom to the right side of the tab control we find that there’s no way of associating any tests either.


Being that this was the first time I looked a this particular feature of Test Manager I must say that I got a little intrigued to say the least. After some Internet searching we still came up with nothing but when we opened up the same Test Case in Visual Studio we finally saw the add button (marked with … in the picture below):


Digging deeper

So it got very clear to me then that this behavior was by design but I still felt that I needed to go behind the scenes to see how this is solved because in the end Test Case is just your average Work Item Type which is defined in XML.

Looking at the Automation Status field in the Test Case WIT XML you’ll see this:


As you can see in the XML you’ll never see the automated state if you haven’t assigned a Microsoft.VSTS.TCM.AutomatedTestId value which is exactly what you do when you associate a test with the add button like the picture below:


Looking at the Associated Automation tab in the Test Case WIT you’ll see this:


As you can see the Associated Automation tab implemented with a control called AssociatedAutomationControl. After some investigation with my favorite reflection utility .Net Reflector I found this section marked in red:


It looks like depending on which ServiceProvider that is used when creating the AssociatedAutomationControl the Add button will be visible or not, TADA!

To sum things up:

  1. You can’t associate automation with unit tests within Test Manager
  2. You can associate automation with unit tests within Visual Studio
  3. All this is because the ServiceProvider associated with the current AssociatedAutomationControl controls the visibility of the Add button in the Associate Automation tab.