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.



Build partially succeeded, but hey no (obvious) errors!

The other day I was trying out the new excellent “Test impact analysis” feature in Visual Studio – Team Foundation Server 2010 and I stumbled upon a rather mysterious problem as you can see from the screenshot below.

2010-12-04 10-46-21

The build says “Build partially succeeded” but as you can see I had NO build errors and ALL (one) my tests where passing!?!

So the first thing I did was to check the build log by clicking the link View Log as you can se below. 2010-12-04 10-32-13

By the way I really enjoy the new look and feel in Team Foundation Build, its precise, gives me a lot of valuable information and it gives me access to the most common command.
Anyway I browsed through the log and found this little piece of information hidden amongst all the other good stuff.

2010-12-04 10-40-14

Ok, I can see that I have some sort of Test Run Error so my first instinct was to run another build. But this time I was going to use another great new feature in Team Foundation Build i.e. the ability to set the type of logging verbosity needed for the build. I started a new build but this time I chose the Diagnostic level of logging instead of normal. Take a look at the picture below:

2010-12-04 10-38-28

Unfortunately the Diagnostic level didn’t help me much with the problem at hand and it took me a while before I found that my “Test Results” window was minimized and in that window was the solution to my whole mystery. As you can see when I opened  the “Test Results” window there is a warning and a link to the problem.

2010-12-04 10-41-48

Following that link gave me the precise clue to the problem:

2010-12-04 10-42-54

and the solution was easy to fix:

2010-12-04 10-43-44

So remember keep the “Test Results” opened at all times and you’ll avoid spending time chasing mysterious non existing errors.



Building and Unit Testing .Net 4.0 with Team Build 2008

One of the tasks this week was to install and configure a new BizTalk 2010 build server in my clients environment. Pretty straight forward you may say huh? Well it would be if my client was using TFS 2010 but in this case we’re talking about a TFS 2008.

There are lots of posts like this great post explaining how to do this and the building part worked fine. But I kept getting error telling me that unit tests where not able to run because I didn’t have the correct version of Visual Studio installed. Anyway here are the steps I followed to succeed with this endeavor:

  • Install BizTalk 2010 compilation components
  • Installed Team Build 2008
  • Installed Team Build Service Pack 1
  • 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\
  • Restarted the Team Foundation Build service
  • Tried a simple Hello World application without unit tests and the build worked fine.
  • Added some unit tests to the Hello World application and got error 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
  • Installed Visual Studio 2010 Premium
  • Got new error telling me that there was some problem with workspace creation during build, found this solution.
  • Changed the property $(COMPUTERNAME)_$(BuildDefinitionId)_$(BuildAgentId) to $(COMPUTERNAME)_$(BuildDefinitionId) in the file %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\TFSBuildService.exe.config.
  • Got back the same old 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
  • Installed Visual Studio Team System 2008 Development Edition
  • Finally the build worked fine and all the unit tests ran successfully!

Hope this will summarize some of the issues you might run into when trying to build and unit test .Net 4.0 applications with Team Build 2008.