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.
    image
  • 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.

    image
    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:
    image

  • 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.
    image
    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.
    image
  • 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:
    image
  • 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:
    image
  • 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.

Enjoy,

Hugo

2 Replies to “Yet another post about Team Build and the 260+ char limit”

  1. As a developer, I can say the I also tend to not use the feature in VS to create a folder for the solution (default when creating a new solution).
    Instead, when I create a new solution I will start by creating an empty solution project (with the default name of solution1.sln and allow it to create a solution folder). Then I use save as an save the solution file as e.g. JL.Examples.Blog.sln at the root level.
    So my structure will look like this (–> means folder)

    Source –>
    JL.Examples.Blog.sln
    JL.Examples.Blog –>
    ….(all the files in the project)
    JL.Examples.Blog.Tests –>
    … (all the files in the project)

    I can then use solution folders, as you stated Hugo, to structure the projects inside the solution in VS but in the file system they are all at the root level but separated by using a good namespace hierarchy.

Leave a Reply

Your email address will not be published. Required fields are marked *

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.