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.


Comments (23)

  1. Rosyna says:

    What about that hack to allow for 32k characters? Is that not applicable in this case?

    "The Unicode versions of several functions permit a maximum path length of approximately 32,000 characters composed of components up to 255 characters in length. To specify that kind of path, use the "\?" prefix."

  2. Garry Trinder says:

    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 for more information here.

  3. Buck Hodges says:

    Buried in the tfsbuildservice.exe.config file are a number of options that control key aspects of the

  4. Guy kolbis says:

    I am working on an automatic build for one of my customers. When I initiate the Get task that gets all

  5. I finally ran into this today–my build wouldn’t execute because my path name was longer that 259 characters.

  6. Maximum file path length in TFS Team Build

  7. Mick.Lang says:

    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.dll

    and 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.

  8. Lettere al Genio del Male: Team Build e il problema dei 260 caratteri…

  9. This post applies to mostly to Team Build 2005 but users of later versions of TFS may find this useful

  10. If you are creating multiple build types, i.e. daily, weekly, continuous and others for a Team Project

  11. ZaydKara says:

    One of our development teams experienced a &#39;Workspace already mapped&#39; problem when trying to

  12. Maximum file path length – Windows and TFS

  13. Maximum file path length – Windows and TFS – Part 2 – error CS0006: Metadata file could not be found

  14. I’m a big fan of Team Build, it keeps the project rhythm going and without it there is no real way of

  15. 9823758297 says:

    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

  16. Nick Walker says:

    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.

  17. ethany says:

    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.

  18. fransisco03 says:

    I agree with ethany. Long Path tool is truly a very versatile tool. Its sure to sort out this type of a problem.

  19. anthonyk says:


    I suggest you to download new Long Path Tool software that simply allows you to work easily on Long Path files.

    Thank you.

  20. Aditya Prakash Roy says:


    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

  21. keywin says:

    Long Path Tool helped me in this situation

  22. freakydinde says:

    mklink does the tricks well

    " mklink /J C:ShortPath C:VeryLongPathSoLongPath "

    it create a kind of shortcut, you can then assignate your TFS project to C:ShortPath