Fix 260 character file name length limitation
I'm now forced to run some NodeJS projects inside a Docker VM on windows because of this ridiculous file limit.
LS Dev commented
MIcrosoft, has this issue been addressed/fixed in Windows 10???
Or are we going to be stuck with this 260-character for the next decade as well? Surely there was something to be learned from the infamous assumption that "we'll never need more than 640K RAM".
Yes 3 votes for this issue too. 2600+ votes must be pretty high up on the tree. Disappointing to see the slow adoption for fundamental issues such as path length, 64-bit tooling, running dot net processes as 64-bit (we had to fight tooth and nail to stop the default being x86 which is pretty incredible), 64-bit EnC. Those things are really foundation blocks for the dev platform but Microsoft tends to toss them straight into the "too hard basket".
man this is pretty crazy in the year 2015... this is a dark ages limit...
hello friends,i suggest you long path tool, its awesome
Yes, this problem is mostly thing why developers are converting to MAC. It's nothing else I hear in office that "npm is not working, ******* windows"... and sadly it's not npm issue directly because of this max path problem. So please fix this is next release if you want also us developers use windows.
William Bosacker commented
@digiface: All versions of Windows since Windows 2000 (both workstation and server) are Windows NT, and there is no difference in code between workstations and servers.
what is windows NT doing inside windows 8.1
Mohit Raghav commented
please fix this issue!
Fabian Wohlschläger commented
Please fix this issue.
hello friends, try long path tool,its really helpful.
Solution: create an opt-in option (set true by default) in Visual Studio that allow for infinite file names. For those old-timers that need this constraint, they can disable this option.
William Bosacker commented
For those visiting here for their first time, this issue has plagued us for over 12 years, and while some people have come up with work-arounds that work for them, no current work-around works for everyone. The fact that the .NET Framework Core is now open source does not mean that just anyone can contribute, as Microsoft is still the gatekeeper for all code check-ins. However; it is probably a HUGE factor as to why they have kept my Connect ticket alive:
If you want to truly get this fixed, please vote at the link above.
Will Buik already declined it
please solve this problem :(
I am too running into this problem. Very annoying!
@Stelvio How to you tell TFS to use your link instead of the full path?
Well, I found a workaround that ALLOW work with path with more than 260 chars.
Disclaimer: I've tried this trick only on Windows 8 x64 and Visual Studio 2013
So, to make it work I've just create a junction to the folder with the mklink command:
Assume this is the original path: d:\very\very\long\path\to\solution\folder, you can obtain a short link as d:\short_path_to_solution_folder just jaunching this command from a dos shell as administrator:
mklink /J d:\short_path_to_solution_folder d:\very\very\long\path\to\solution\folder
change source and destination path to you needs
This is a ridiculous issue that pops up at the most annoying times and is hard to work around. You and your team come up with a great project structure. You go Publish BOOM "path error" because WCF creates ridiculously long paths in the proxy files and although Visual Studio was able to create them (and use them!) you can't copy them?!?! Fine. You move your project to the root (lots of issues around that, but I digress).... a few months down the rood BOOM "path error", this time because App_Themes creates a fairly deep tree structure. I hear Node.js is unusable because of this too.