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
Nodejs is basically unusable on windows and you certainly can't deploy a nodejs app to azure, unless its an express "hello world" app.
Why don't you reallocate the resources being used on the nodejs tools for visual studio? How about reallocating resources working on anything nodejs related for azure?
What's the point of having nodejs tools in visual studio or supporting nodejs on azure if you cant use nodejs or deploy a nodejs app to azure?
How is 260 characters an appropriate limit for a file name in this day and age?
I am of the opinion the decision to push this aside is short sighted and can be comparable to our favorite meme "640k of memory is enough for anyone". Is it time for the new meme “The 256 character path limit is enough for any anyone.”
The fundamental point is we are tired of having to work around this limitation.
The workarounds are not always zero cost or easy. The situation is when the path limit is reached it breaks progress for a task to be completed on the Microsoft Windows platform. Someone must search for a workaround and then determine if the workaround is practical for their situation. Not everyone is trying to delete a file that is beyond the limit. Not everyone is trying to access a directory that is on a local device. The workarounds are not universal to all situations dealing with accessing a path that is longer than the set limit.
The reason you see votes for this and people posting is because the workarounds are not making their job easier or helping them complete their tasks. The path limit is causing unexpected issues which to address requires unmeasurable cost to the end users to work around and to avoid.
I had a simple task I wanted to perform which requires the input of all data in a directory tree. Unfortunately the tree has paths too long for Windows to handle. I have burned time searching for a workaround. I now have to dig into the workarounds and determine which one is going to work for me.
I have been moving the servers hosting network directory shares away from Windows servers to eliminate dealing with the path issue on the host of the shares.
The new enhancements do nothing to solve the problem we face when we hit the file path is too long error.
How about implementing separate LongFileInfo, LongDirectoryInfo, and LongPath objects, similar to what AlphaFS did, or LongPath flags in these object constructors defaulted to false, to allow those who want/need this functionality to utilize it right from .NET, and then the ecosystem can start utilizing them?
i now use mklink to shorten my path :
mklink /J C:\ShortPath C:\VERY\LONG\PATH\I\WANT\TO\SHORTEN
then in TFS you map on C:\ShortPath
Eric Brown commented
I'm wondering how this issue is going to be fixed given the .NET framework has been open sourced and Microsoft is actively working on Linux versions of the various classes in the framework.
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
Scott Galloway commented
Over on Connect this has been reopened as active (just if like me this was your first hit ;)) https://connect.microsoft.com/VisualStudio/feedbackdetail/view/932051/long-filepaths-260-characters-are-not-supported
Scott Galloway commented
With node, npm and other tools becoming core to the VS 2015 web build process this is now an issue which will impact EVERY user. It's a ridiculous joke...
Opensource all your ****** products, and let the comuunity help you.
Reinhard Kuhn commented
Having followed the discussion for quite some while I can't help but conclude, that this entire "uservoice" site in the meantime is nothing more than a joke that entirely gets ignored by Microsoft.
What a pity!
Howsoever long the path may be, you can always rely on Long Path Tool. Its sure to sort out your problem.
Eric Brown commented
The community has created a clone of this issue given Will Buik declined this and essentially told everyone: "Too bad." Here is a link to the new issue: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4954037-fix-260-character-file-name-length-limitation
This is a serious issue, not only for VS but for all MS products.
I recently had to port my code to Scala and move to a Unix machine because the service that I was running was depending a lot on file concatenation. Because of this situation I had to move to a different OS. Is this normal? The NodeJS community suffers from the same issue with their npm. And things are becoming more and more vocal. Besides this, messing with the system PATH is what gives Windows that feeling of slowing down with time(the more you use it, the slower it gets). I have just tested this on 2 machines, their OS was not reinstalled in 2 years now, and the findings are relevant. I am really questioning if this issue is something that will stay as long as windows exists. So far, from your explanations and the way it affects all of your products it seems so.
"This response is a ******* joke, frankly. You know it's a problem: fix it."
Very much agreed. This is a problem that could have been solved at the time the UNICODE API calls were released. How long ago that was? I'm guessing at the very minimum for consumer OS, that was in WinXP.
@WillBuik This needs to be addressed at some stage. Yes it will be at the cost of something else but that is always a reality. This is a massive limitation in Visual Studio and simply needs to be addressed at some stage. When are resources planned for it? 2020? 2030? 2050?
William Bosacker commented
FYI, every single one of these references to "Long Path Tool" are from the same person, the author. Whenever you see a post like those, please click the "FLAG AS INAPPROPRIATE" link, as he is trying to sell his tool through this and other sites.
Wahid Haq commented
I suggest to try "Long Path Tool" program. It’s really work for me.
Since you can't vote here anymore, here is a duplicate request at https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4954037-fix-260-character-file-name-length-limitation
Try LongPathTool to solve the error..