Team Build and 260+ Character Paths

A fairly common issue in Team Build v1 involved builds failing due to paths that exceed 260 characters - see this forum post, for example.  260 characters is not a Team Build limit - it is a Windows limit.  See here for a reference on this topic...

Team Build builds do tend to run into the 260 character limit more often than non-Team Build builds, however, because Team Build builds occur within a working directory on your build machine which already contains a bunch of characters. 

In Team Build v1, you could specify a specific working directory for each build type (and even override this when starting a build).  Let's say that you use the directory "C:\BuildLocation" for a given build type.  To ensure that individual build types avoid the workspace conflicts that would occur if they tried to use the same working directory, Team Build v1 then appends the team project name and the build type name to this working directory.  So - if your team project was called "Framework Projects" and your build type was called "Nightly Build", the build type working directory would end up being "C:\BuildLocation\Framework Projects\Nightly Build". 

But wait - there's more!  Your source files will then be placed in a subdirectory called "Sources" (while binaries will end up in "Binaries" and test results in "TestResults").  So - the full working directory in which your build will take place in this case would be "C:\BuildLocation\Framework Projects\Nightly Build\Sources" - that's 57 characters right off the bat, leaving you only 203 remaining before you hit the Windows limit...

We've tried to give you more control over this issue in Orcas by making two changes.  In Orcas, a working directory is associated with a Build Agent (more-or-less a build machine) rather than a Build Definition (formerly known as a build type).  Whatever you specify for this directory will be the entire path used for the base working directory - Team Build will not append the team project or definition name to the end.  To ensure that individual build definitions can still avoid the workspace conflicts that would occur if they tried to use the same working directory, Team Build Orcas provides two variables that can be used in these working directories - $(BuildDefinitionPath) and $(BuildDefinitionId). 

$(BuildDefinitionPath) expands to "<team project name>\<definition name", or essentially the same thing that was used in v1.  So - if you don't normally run into the path length issue, you can just keep using the same sorts of paths that were used in v1.  $(BuildDefinitionId), on the other hand, expands to the string representation of the integer identifier of the build definition in the Team Build database.  This will typically be much shorter than $(BuildDefinitionPath).  (FYI - you can also use environment variables with the same syntax.  For example, you could do something like $(HOMEDRIVE)\$(BuildDefinitionPath) to get something like C:\TeamProject\Definition)

Additionally, we've given you control over the three subdirectories used by Team Build - you can modify the keys "SourcesSubdirectory", "BinariesSubdirectory", and "TestResultsSubdirectory" in the configuration file for the service that executes builds on your build machines.  (Typically this will be something like %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\TfsBuildService.exe.config)

So - if you have really long paths and need Team Build Orcas to get out of your way, here's how to get really short working directories:

• If you can dedicate a build agent to a single build definition, you can use something like "C:\b" for your working directory.  If you then use "s" for your SourceSubdirectory, your full working directory for the build would be "C:\b\s" - a savings of 51 characters.
• If you need to use a build agent for multiple build definitions, you can still use something like "C:\b\$(BuildDefinitionId)" for your working directory.  If you have fewer than 1000 build definitions, your full working directory would be something like "C:\b\123\s" - still a savings of 47 characters.

-Aaron

Comments

• Anonymous
  June 20, 2007
  The comment has been removed
• Anonymous
  June 20, 2007
  Nope - there's no way I know of to get that to work here.  Build involves too many individual tools (Team Build, MSBuild, csc.exe, vcbuild.exe, aspnet_compiler.exe, etc.) that all pay attention to the 260 character limit - at some point, something is guaranteed to "barf" (that's a technical term) on the path and fail the build.The important bit in the quote you mentioned is the word "several".  Many versions of functions do not permit a maximum path greater than 260, including the .NET APIs, which are used extensively by Team Build, MSBuild, etc.  See http://blogs.msdn.com/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx for more information here.
• Anonymous
  July 20, 2007
  Buried in the tfsbuildservice.exe.config file are a number of options that control key aspects of the
• Anonymous
  December 13, 2007
  I am working on an automatic build for one of my customers. When I initiate the Get task that gets all
• Anonymous
  February 23, 2008
  The comment has been removed
• Anonymous
  February 26, 2008
  Maximum file path length in TFS Team Build
• Anonymous
  February 27, 2008
  I've seen numerous people saying the limitation is less than 260 characters with the limit varying from person to person.  I think I know why:-I've run into this problem in my build.  I was getting CS0006 on assemblies referenced by a couple of projects, when several other projects were compiliing successfully referencing the same assembly.  The absolute paths of both the project and a (file typed) referenced assembly were a lot less than 260 characters i.e the referenced assembly absolute path was about 140 and the projects path was 160.However when you took the relative path of the referenced assembly from a project directory.................LibCompact FrameworkWindows Dynamic Mobile FrameworkMicrosoft.Dynamics.Mobile.Framework.Controls.dlland concatenated that on to the absolute path of the project directory referencing the file, if the end result was greater than 260 characters then that project would fail to build with a CS0006 error.This means the limitation is about twice as constricting as what you've described here.  It would be OK if the limit was just the absolute path to assemblies.  However when this limit is applied to the combined length of the project and the relative path to a referenced assembly then this limitation is quite constricting.I think you guys really need to look at this and fix it.
• Anonymous
  March 26, 2008
  Lettere al Genio del Male: Team Build e il problema dei 260 caratteri...
• Anonymous
  June 16, 2008
  This post applies to mostly to Team Build 2005 but users of later versions of TFS may find this useful
• Anonymous
  July 08, 2008
  If you are creating multiple build types, i.e. daily, weekly, continuous and others for a Team Project
• Anonymous
  July 08, 2008
  One of our development teams experienced a &#39;Workspace already mapped&#39; problem when trying to
• Anonymous
  August 03, 2008
  Maximum file path length - Windows and TFS
• Anonymous
  May 16, 2009
  Maximum file path length - Windows and TFS - Part 2 - error CS0006: Metadata file could not be found
• Anonymous
  May 22, 2009
  I’m a big fan of Team Build, it keeps the project rhythm going and without it there is no real way of
• Anonymous
  November 30, 2010
  Khushi itni ho ki tum dikha sako,Gum bas itna ho ki tum chupa sako,Zindagi main kam se kam ek rishta toa aaisa jaroor rakhna,Jiske liye tum mood off main bhi muskura sako
• Anonymous
  July 14, 2011
  Thanks for this tip, it helped me out a lot. However, I just discovered today that C:b$(BuildDefinitionId) will only work as long as a single agent on the machine is used to run the build. If the machine has multiple agents, it will fail sooner or later. The solution is to add $(BuildAgentId) back in, or give each build agent a unique path for the working directory. A deeper solution would change the logic in the template that initializes the workspace name so that both agents use the same workspace.
• Anonymous
  April 16, 2014
  Have anyone used Long Path Tool as this Tool is very useful if you are having problems in deleting, unlocking, copying and even renaming files that are considered filename too long by your system. Yes, these problems can occur even while using the latest Windows Explorer or FAR in managing your files.
• Anonymous
  June 17, 2014
  I agree with ethany. Long Path tool is truly a very versatile tool. Its sure to sort out this type of a problem.
• Anonymous
  July 14, 2014
  Hello,I suggest you to download new Long Path Tool software that simply allows you to work easily on Long Path files.Thank you.
• Anonymous
  November 18, 2014
  Hello,you simply need to copy your project folder from your path to root directory (ex:-d:abcabcxyzYourProject to d:YourProject  )Maximum file path length Error Solved.this trick work in my case.thank you
• Anonymous
  January 07, 2015
  visualstudio.uservoice.com/.../2156195-fix-260-character-file-name-length-limitation
• Anonymous
  February 11, 2015
  Long Path Tool helped me in this situation
• Anonymous
  March 02, 2015
  The comment has been removed