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.