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
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..
This is nothing short of pathetic. You can try long path tool for getting a good solution. Hope it will be works good. Thanks
Microsoft is just like this they make all kinda bs. Cortanan coding your software but they will NEVER EVER dare to fix anything which annoys the living **** out of everybody. I hope there will be new king in town some day and MS is just a bad memory after that.
Maybe with the advent of MS open sourcing .Net and bringing the runtime to Linux, we will finally have the sane IDE with MonoDevelop
Andrew Clancy commented
Have you done an estimate of the cost of not doing this vs doing it? In the scheme of things, the cost of not doing it could run into billions, if it means further erosion of your already far-too-late-to-the-market cross-platform support
Anyone trying to work on multiple operating systems knows what a pain ********** this arbitrary restriction can be. It is, as many people have said, 2014. More to the point, it is not the mid-90s. People have a choice, and so long as the Windows ecosystem throws up annoyances like this, more and more people are going to move to OSX or Android/Chrome OS. So lame!