Fix 260 character file name length limitation
The 260 character limit on file paths really gets in the way of having a deeply-nested project hierarchy. It's only there as backwards compatibility with the old school APIs, and has no place in any sort of modern development environment.
We should be able to work with file paths of whatever size we want.
Hello everyone and thank you for the feedback and for voting on this issue. We understand that this can be a frustrating issue, however, fixing it requires a large and complicated architectural change across different products and features including Visual Studio, TFS, MSBuild and the .NET Framework. Dedicating resources to this work item would come at the expense of many other features and innovation. Additionally, if we removed this limitation from our first party tools it will still likely exist elsewhere in Visual Studio’s ecosystem of extensions and tools. For these reasons, we are declining this suggestion and returning return everyone’s votes so they can be applied to other items. In the interest of delivering the most value to our customers we sometimes have to make very difficult cuts, and this is one of them.
Visual Studio – Project and Build Team
Too avoid conflict with existing products make a "I know what I am doing checkbox" that does allow longer path names.
Use "Long Path Tool" for easy fix regarding long paths..
William Bosacker commented
Windows supports file paths up the 32768 characters long. The only limitation is that each folder & filename within the file path cannot exceed 256 characters. There is absolutely no excuse for TFS not supporting the file structure as it exists. The .NET Framework already supports it, so Will Buik's statement is incorrect and uninformed. This topic needs to be reopened.
Alex B commented
The problem is Windows itself.
For years we regularly receive complaints from our customers about long paths, created by third party server applications, that cannot be handled using standard Windows tools (Explorer, etc.).
In my opinion the poor performance regarding file and path names, disqualifies Windows as a decent platform for applications that handle files.
WHY tHIS happen ????
Chris R commented
I, for one, am extremely disappointed that this has been declined as a suggestion. I have come to expect no less from Microsoft though. I believe that this is not directly related to Visual Studio but instead is a failing of Windows, that has never been tackled due to the fact that it is an inherent limitation of NTFS and FAT32 formats. Oh well - this just lends more credit to me learning Python on a Linux development machine, or even better, the Mono project on Linux - which gets around this kind of issue.
"semantically-empty verbiage" !!
Wow, I didnt realize the level of discourse here was so impressive!
I use the automated SUBST method (that I described below) for file-by-file full disk copies to deeply nested target pathnames. Works like a treat. No "idiots" required!
One more shocking statement by MS representatives which once again boils down to some semantically-empty verbiage.
We have a display of several forms of sister-kid excuses and band-aids here:
o) circular reasonning: would need .NET fixing it, which would need VS fixing it...
o) overdue amplification with ample distortion rate: "large and complicated -->architectural<-- change" Woooaww! The blueprint of the Cathedral is at stake.
o) even more thoughtless advice from senior consultant collegue: map long base paths to drive letters. And how many drive letters do we have, idiot? Ow, that many? And when we get out of drive letters? Resign and change to a job not involving computers (plumber or navvy)...
It would have been simpler to just answer: *** you guys". You are NOT correct, so no chance to be it politically.
Let´s say I add the EnterpriseLibrary.WindowsAzure.TransientFaultHandling NuGet package to my solution.
It just used up 169 characters of the 260. It leaves me with only 91 characters to organise my own namespaces and types. We are hitting this limitation repeatedly and spend alot of time on trying to shorten our namespaces.
Microsoft also recommends us to use this pattern for naming our namespaces
Often the Solution folder equals <Company>.<Product>
Please! Clean up your old mess before creating new ones.
Clay Ferguson commented
The problem with Microsoft is that they must maintain more 'backwards compatibility' than most companies, and sometimes by 'fixing' a problem it is NECESSARILY required that that change can BREAK much existing software. I know this for a fact from actual MS developer friends. Microsoft is sort of stuck here. They can't move forward and they can't move back. They just must stay the same. Solution: Linux. :) Ubuntu is my recommendation.
Aasdf Sadf commented
At least they didn't "fix" it like they "fixed" their 3-monitor-NVidia limit: force NVidia to limit Linux users to 3 monitors as well. :(
It's trivially easy to work around that limit by using the venerable DOS SUBST command to successively map free drive letters to each 255-odd chars of the path.
For example, to access files in c:\humungously\giganticallylong (assuming this path exceeds the normal path length limit), just map (say) E: to c:\humungously, then F: to E:\giganticallylong.
Then you can access any files in c:\humungously\giganticallylong, via drive F (eg. F:\blerg.txt). Repeat for as many drives are required to cover the path in question.
This method works as long as each individual part of the path is <= 255 chars. I imagine that most PCs would have at least 20 free drive letters, thus extending max path length to more than 5000 characters, using this technique.
This is so easy that I wrote a VBScript class to do it. Give that class an excessively long path, and it maps the required drive letters and returns the last one (F, in the above example). You could use the same technique - give your class a long path to your deeply nested directory, and get back a drive letter that you can use to access files in that directory.
Or you could read all the ridiculous comments (here and in hacker news) and conclude this was impossible and will lead to microsoft's imminent downfall! LOL
TC (ex MS MVP)
John Doe commented
Would it be more reasonable to request that just PART of this be fixed? For example, I work on projects that use MSBuild but not VS or TFS. It's probably a lot easier to fix just MSBuild (if it's even broken, which I'm too lazy to check), and there's no downside to fixing it here even if VS/TFS can't get fixed immediately.
The "elsewhere in VS's ecosystem of extensions and tools" excuse is lame. Microsoft doesn't use that excuse in other areas. Just because somebody else's software might be bad (and you don't even say for certain that any third-party programs are affected!) doesn't mean you shouldn't fix yours.
I think I speak for many of us when I say that "other features and innovation" don't count for a whole lot if they're full of bugs.
As an aside, it's kind of scary that you say allowing arbitrary-length filenames "requires a large and complicated architectural change across different products and features". That does not inspire confidence.
This is why we can't have nice things.
jewish adolf commented
developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers!
Lame. But that's what you expect from Microsoft in 2013.
Thank you for giving my company a reason to move away from TFS and Visual Studio. I hope those cool new innovative features are more important than customers!