TFS Changing the Build Agent Working Directory

Question

I'm getting the same kind of error as described here. I'm running in to the file name limit of windows in TFS Build. The answers to this question suggest redefining the build agent working directory. I'm not sure if I should do this. I have a few questions...

1. Does changing the build agent working directory affect me, or everyone using the build agent?

2. The build agent is not ran by me, it's on a different computer controlled by a different department in our company. I can get to the "manage build controller" settings, and I seem to be able to make this changes, I'm just scared to!

Answer 1

There are a couple of options here, changing the build directory on the build agent, in Team Explorer right click on the "builds" folder and select manage build agents. Select your build server(s) and change the build folder to something like "e:\b" (or even "e:\" if that's all you use that drive for) This will change the build working directory for that build server. This will shave a few characters off the working directory.

In addition to this you can map the workspace used by the build as far down the tree as possible. This is a good idea to do even if you're not running out of characters on the path as TFS uses the workspace to determine which code to get for your build.

e.g. If your workspace is mapped to $/TeamProject = $(SourceDir) this means TFS will get all of the code in the team project for the build. Even if you only want 1 solution from 1 branch

Consider a Team Project set up like this

`$/TeamProject/DevBranch/Docs
                        /Source/Solutions/Solution1
                                         /Solution2
                                         /etc...
                        /More Stuff
              /MainBranch/[Same As Dev]
              /HotFixBranch/[Same As Dev]
              /ReleaseBranch/[Same As Dev]`

If your workspace is mapped to $/TeamProject you're going to be getting everything from TFS when all you really want is the code in the "solution2" folder from the dev branch. Change the mapping to $/TeamProject/Devbranch/Source/Solutions/Solution2 and you've just shaved about 60 characters of the length of the path. In addition to this you'll speed up the builds as it will only get the code they need.

Answer 2

The full qualified name must not exceed MAX_PATH which is on Windows 260 characters. In reality there different values used for various tools.

The GAC e.g. does reject file names which exceed 256 characters. With file name the path and the file name itself is meant. TFS is built upon Windows hence the same limitations exist for TFS builds. The only feasible solution is to use a workspace directory which is as short as possible to limit the amount of issues you will run into. You could try to subst the workspace directory to make it even shorter but the fundamental file system limitation will not go away.

Yes Microsoft should solve this issue but in reality it is not feasible soon. Any tool (MS and non MS) which is used during the build will run into the same limitations. At best the tools will crash when the file names get too long. In the worst case you get corrupt binaries without noticing. All applications which are written in C/C++ use for file name buffers a MAX_PATH+1 sized buffer. Even if Windows would allow such file names (there are ways but ...) the buffers of nearly all applications would be too small to make use of them.

You are not alone we all suffer. On the bright side this limitation does prevent nitpick architects to enforce naming conventions which exceed MAX_PATH alone with the target name.

Answer 3

It is used by every build task that uses that build agent so yes, it could affect multiple people. If you're running into a path limitation, you should definitely change the working directory. I would just clear it with the other people in the department before you proceed, just to make sure everybody knows what's going to be done.