In the last month I have had two separate clients have issues with how their working directories were setup in their TFS builds. First a system drive was running out of space from a large amount of new projects being built, and second some builds were failing due to some file paths being over the OS enforced limit of 260 characters. These were caused partially because it is not immediately obvious where the working directory for the build server is located when you create them. This post is a quick review of how to manage the working directory and avoid the two issues above.


The working directory is the location where the server will place all the source code for a TFS project's build. It is logical to think that since you are asked to select a workspace during the creation of the build definition, that the build would use the local directory set in that workspace. That is not the case.



If you create a build with most of the defaults the working directory will be a temp folder under the Local Settings directory for the user that the service runs under (which is usually TFSSERVICE). You can see this is the buildlog.txt screen shot here.


So by default all the source code for all the builds will be on the system drive (most likely) and will start out in a directory path that can be 80 to 100+ characters deep already giving you not much room before you will hit the 260 character limit.


So you may initially go back to the build definition to point to another directory on another drive with a shorter path. But you will see that while you can set the drop location where the compiled output of the build will go, the working directory is not set in the build definition.



The working directory is actually set in the build agent in the Working Directory field (funny enough). By default this will be $(Temp)\$(BuildDefinitionPath). The $(Temp) is what points us to the user's temp directory under Document and Settings.



So we can change this to point to the directory and drive of our choice to prevent our system drive from being overloaded and hopefully avoid reaching the 260 character limit when the source code is pulled down.