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
You can also use Long Path Tool to sort out this problem.
coming across internet to find out we still work with 8 bits
:( feel sad!
PS: Have Bill Gates pay for it out of his own pocket. Hire extra help and get it resolved ASAP across the various applications and their plugins/tools.
I am sorry but that's bull****. Microsoft receives horrible perceptions from various people due to the lack of true customer service. Why do you think Apple is still a huge competitor? Even though they have their issues as well, Microsoft has been on a track record for years. Hopefully this is fixed in Windows 9. But I highly doubt it.
Arunava Ghosh commented
No need for so much. Just download B1 Free Archiver from http://b1.org/. It will extract any damaged files without the extracted file getting corrupted.
@Will Buik - This is a ridiculous answer to a problem that everyone using Windows in a professional way comes across. I am astonished that you feel this problem is not important enough to fix.
This is 2014 and problems like this should simply not exist in a modern operating system. It reminds me of the problem with VARCHAR in SQL server - the limit of 8000 characters was a pain and using TEXT columns was not an acceptable answer. Now we have VARCHAR(MAX) and (almost) everyone is happy. You have to stop carrying the technical debt into new versions and draw a new base line at some point. That point is now.
Absolute crock of cr*p, this is typical - oh it's too hard, and we're adding stuff nobody asked for or really needs rather than fixing critical stuff in the background... *sigh*
This issue has been around for over 12 years, so I have created an issue on Microsoft Connect to fix this BUG! If everyone would go to the URL below, login, and Click the up arrow to vote for this, Microsoft will be forced to respond. While these uservoice forums are helpful, they aren't actually tracked in Microsoft's issue system. Microsoft Connect is the public portal to their issue system. PLEASE VOTE!
linda carter commented
stop adding useless features and fix this, geez someone should be fired at MS.
Arjen van Putten commented
Is there anyone with a workaround for this issue? I changed my IntermediateOutputPath already to almost root..
This limitation is such a pita to work around. Pretty much adding 1 or 2 folders to your VS project and you risk hitting this in TFS.
So because it is a lot of work the feedback is declined? That is pretty poor customer service. Delivering the most value to your customer would be delivering that which is being asked for by your customer.
Colin Bowern commented
I think you need to start chipping away at this problem. Node.js re-introduces this as well:
I had to write a TFS build activity that could handle cleaning up node modules:
Matthias Goetzke commented
So the reasoning is to not fix it ever because it a lot of work. They could have said we t take out the limitation step by step .. And realistically they should have started doing that years ago. Thru would have finished by now and the few extensions not following this would have been shunned.. But Ms doesn't really have pride in what they deliver. It's a little like s showing the finger to the people that removed this limit from the fs.
@anthonyk: As I told you in the other thread, LPT does nothing for VS or TFS. The limitation is hardcoded into the applications themselves, along with the hard coded limitation of the .NET Framework, and LPT does absolutely nothing to change that.
Simply download new Long Path Tool software that simply allows you to work easily on Long Path files.
Adam Velebil commented
I can't decide what is more ridiculous - the limitation itself or the fact that the suggestion to fix it was declined.
@James Neave: The majority of us don't map TFS to a folder under "My Documents", we're already using a short path like C:\Work or C:\TFS, and we're still running into the 260 character barrier. Try working on a large web application, or creating multiple libraries, and you'll run into the same problem.
James Neave commented
One workaround we use is thus:
We have our Projects folder in My Documents, under that lots of long, descriptive branch names and random failures due to path length.
But we get around it by mapping the Z: drive to that Projects folder.
It does cause issues where that drive isn't mapped under all the user accounts you need but I'm sure that could be solved as well.
We also use it in build scripts for various things, there we use the subst command to point a driver letter at a folder on a local disk.
long path tool can help full on this situation. Thanks