TFS 2010 - Error occurred during copy: Path too long

Question

We have an ASP.NET MVC project that we want to create a publish package from during an automated build. The build is using the unmodified default template with Arguments /p:DeployOnBuild=True /p:CreatePackageOnPublish=True.

If I do a WebDeploy directly to a server it is working fine (if I change /p:CreatePackageOnPublish to false) but I would prefer to just create a package that I can deploy during a Lab build.

The error message looks like this:

TF270002: An error occurred copying files from 'C:\Builds\19\Binaries' to '\nas\Build\Drop\MyProject\MyProject_Development.Test\20120209.1'. Details: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

The first part of the problem was the build folder path was too long (274 characters) but after changing the working directory from $(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath) to $(SystemDrive)\Builds\$(BuildDefinitionId) it's down to 230 characters as the longest path so it should be ok.

The problem now seems to be the path in the drop folder, even though it's root path is not that long by itself \\nas\Build\Drop\MyProject, the build name and Build Number Format quickly adds to the length MyProject_Development.Test\MyProject_Development.Test_20120208.1. After that all them nested paths create really deep folder structures _PublishedWebsites\MyProject.Web_Package\Archive\Content\C_C\Builds\19\Sources\MyProject\Source\MyProject.Web\obj\Debug\Package\PackageTmp\Content\ui-lightness\Images\ui-bg_diagonals-thick_18_b81900_40x40.png.

So is there any way to get around this problem? I shortened the build number format from $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r) to $(Date:yyyyMMdd)$(Rev:.r) to save a few characters but it's not enough. I guess we could shorten the build name a bit but it would break the naming convention used (Ok, that would not be a really big problem but it would be annoying!) and still it would feel like a short term solution.

What else is there to do?

Patrilineal

Answer 1

The short answer is the path length limitation is really annoying, and you're going to have to spend some (more) time tweaking your file/folder structure to make this work.

For example instead of \nas\Build\Drop\MyProject, just do \nas\Build\Drop (or \nas\Builds) since the project name is also in the build name.

Flatten the folder structure in your projects (do you really need a Source folder under MyProject?).

Also, go vote for the UserVoice suggestion for the TFS team to fix the path length limitations: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2156195-fix-260-character-file-name-length-limitation

Td

I was afraid that there was no better solution to this... I have trimmed as much as possible of the excess (my build is now called M_D.T, really informative) and now it builds although my longest path is 250 characters so it's a bit to close to the limit for comfort. Thanks for your answer and the link to UserVoice! – Patrilineal

Update: the feature suggestion to fix the problem was declined by Microsoft. – Playful

new user voice link, keep the pressure up ;) visualstudio.uservoice.com/forums/121579-visual-studio/… – Winson

This fixed my problem (shortening my path). I was more frustrated that the error provided did not tell me which path/configuration was the one that was too long...I eventually figured out that it was the Build Defaults -> Copy build output to the following drop folder (UNC path, such as \\server\share) – Pinup

I wonder: does anyone knows whether this problem exists also if you use the Git repository in TFS 2013? Maybe this could be a possible solution... – Fluting

The path length problem is a problem with Windows not specifically with TFS. So it will happen whether you use TFS+Git, or any other source control system out there. Windows simply does not support long paths. – Td

Answer 2

I know the question is old, but I faced the same problem and I devised to solution to this, although it errs more on the preventing the problem from ever occurring rather than fixing the existing path length condition. It can then be applied once the issue has been - manually - resolved.

Please note that it applies to TFS under git. A similar approach could be devised for TFSVC, although it would have to be run after the code is merged.

Essentially, it's a short script to be run as part of the PR build. It enforces that no file added or modified has a path longer than the one you allow.

It is described in this blog post

Cameliacamella