Friday, November 19, 2010 2:36 PM
I know that there is currently limit on the max file path in TFS 2010, and honestly, I can't believe this limitation still exists! It's the year 2010 and we're using Windows 7 with VS and TFS 2010, with 64-bit hardware and software. Why on earth is this limitation from like 1995 still in place?!? Anyways, sorry for that short rant, I am just very frustrated over this.
We use feature branches at our office, and have a very large solution (around 450 projects separated between 2 VS solutions). Obviously, to keep everything in a nice logical, easy to understand format, we end up with a namespace hierarchy that is several layers deep, which leads to folders that are also several layers deep, creating very long file paths.
When trying to Get Latest on a feature branch of ours, we are getting errors such as:
TF205022: The following path contains more than the allowed 259 characters: C:\dev\TFS\RQ4TeamProject\Dev\RQ4\FeatureBranches\PP_DuplicateDetection\Code\IQ.Enterprise.Integration.Windmobile.ApplicationServices\Service References\Intec\IQ.Enterprise.Integration.Windmobile.ApplicationServices.Intec.ProdInstServiceRetrieveData.datasource. Specify a shorter path.
The case above isn't so bad since the error message actually told us the problem; that the file path is too long. We've had several developers waste days trying to figure out why our solution would build on our local machines, but not on our build server. The only error message we would receive was, "cannot find reference to assembly X". As it turned out, the build server plopped all of the files into a root folder whose path was about 15 characters longer than on our local machines, so assembly X was never being built because its file path was too long, and hence it couldn't be found.
Our solution to this so far has been to go in and start renaming namespaces and assemblies and the like to try and shorten their names, which works, but is a real pain. And as our solution continues to grow, it's going to lead to more obscure and unclear namespaces, making our code harder to understand.
Is there some other solution to this file path limit that I am not aware of? And are there any plans to address this issue in future versions (I sure hope so)?
- Dan - "Can't never could do anything"
Friday, November 19, 2010 8:01 PMShortening your paths is the only solution.
Ewald - Please remember to mark the replies as answers if they help.
- Marked As Answer by deadlydog Friday, November 19, 2010 9:26 PM
Tuesday, March 06, 2012 1:59 PM
We just migrated to TFS, and ran into the exact same problem. In our case, our folder depth and folder names are not extremely deep or long in and of themselves. However, when coupled with the full namespace being generated as file names through Visual Studio's "Add Webservice reference" code generation, it becomes problematic using TFS.
I just put a lot of time making the case for our company to move to TFS only to find that we get this error trying to branch. Our previous source control did not have this issue, and we may end up having to move back.
Visual Studio itself is generating these long service reference files based on namespace. The underlying file system supports longer names. Having clear namespaces and folders makes it easier for people unfamiliar with the codebase to understand your product framework. We can't afford to go through a large codebase renaming all folders and files to something short and cryptic every time we hit this because a code generator names files like this.
Development has evolved. This needs to be addressed. Until it does, it's a huge minus for TFS, and has made it lose my recommendation over other source control systems (there are even free ones don't have this limitation).
heads you live... tails you die..
Tuesday, March 06, 2012 2:36 PM
I am so sorry to hear this message from you. We are aware that this is a very frustrating problem. On Uservoice there is a suggestion to solve this limitation. You can help us prioritize our work by using Uservoice to indicate what you think is important.
TFS Program Manager
Please remember to mark the replies as answers if they help.
- Proposed As Answer by edm2 Monday, November 19, 2012 7:56 PM
Friday, June 15, 2012 3:13 PMWe got the same issue because it generates a guid in the local machine's temp folder. We got around this by changing the registry for environment temp's location to something short (i.e., "c:\t"). Not exactly a perm solution, tho....
Sunday, June 17, 2012 10:34 PMI also learned this week at Tech Ed 2012 that the file path limit will be increased to around 400 characters in VS/TFS 2012. They said the fix won't make it into the RTM version, but should come in an update shortly afterward. Also, they said the reason that they couldn't increase it even more than that was because of sql server indexing, and in order to keep performance good they couldn't increase the max limit any more than this.
- Dan - "Can't never could do anything"
- Edited by deadlydog Sunday, June 17, 2012 10:36 PM
Monday, November 19, 2012 7:55 PM
And Microsoft regards that answer as acceptable? (because of sql server indexing....). They need to revamp the path-length architecture they are using to support their customer's needs. Suppose I told you that all hospitals in a certain town shut down at 5pm because it was not convenient for the workers to stay after that hour. Would you care about their problems? Especially if you got sick at 5:30pm? I don't think so and neither would I. Microsoft better correct this issue or their customers may start looking at other ALM products.