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
Steve Sheldon commented
This problem is all throughout Windows, and I do have to agree with other comments here that eventually this is going to lead many companies to migrate off the platform.
I've hit this issue before with Visual Studio and TFS, surprisingly the project that seems to cause the most paint is a Platform & Practices assembly from several years ago which has like 80 characters in it's name.
We deal with a lot of digital content transmitted to us from vendors where filenames are highly descriptive and may be 100+ characters in length. Copying or moving these files around frequently results in hitting this limit. It's not a problem for our vendors as most are on Linux.
You know what's valuable to me? Fixing the broken system.
"This is something that makes you tear your hair out and buy a Mac." <- Exactly!
Basically, Microsoft has been too busy doing great things like:
-Removing Aero Glass (which most of their customers would actually prefer to have), and producing the ugliest popular (as in "forced on a bunch of unsuspecting users") UI to date.
-Making ugly/gaudy icons (and then receiving backlash and producing yet another set of slightly better icons) when the existing icons were perfectly fine/better than what we have now. (Those of you who didn't participate in the Preview missed out on this fiasco!)
-Mass rewriting core UI functions to slow, memory hogging, and inefficient XAML code when the native Win32 versions we had previously were fine. Most of us Insiders preferred the pre-build 9926 Start Menu, before it was converted to XAML.
-Adding spyware to their system (which many of their users don't want).
...to even care about actually important stuff like this, new technology support, better performance and security in their core OS. It's about time Microsoft should try to keep up with their competitors!
In the meantime, everyone running Windows 10, please open the Windows Feedback app, search for "max_path", and vote up the appropriate suggestion(s). It's the best we can do at this point.
Jack Mott commented
This is something that makes you tear your hair out and buy a Mac.
Igor Varfolomeev commented
This limitation is one of the main things, that make me think that it might be easier to migrate to another OS...
This issue MUST be fixed. It's absolutely unacceptable.
For me it's more important that all other things M$ developed since Windows 7 (e.g. more than Windows 8-10, all recent MS Office versions and all recent versions of MSVS all together). So, for me, "Dedicating resources to this work item would come at the expense of many other features and innovation" is not an answer.
Eventhough I appreciate your answer from October 2013, I'd like to give this is issue an up-vote.
Today is July 2015. Please keep communicating with your customers. Thank you.
As much as I understand this is a major architectural change, it is a fundamental issue that we don't expect to encounter on a post-1990's computer. Not allowing file path strings that are allowed by the operating system demonstrates a failure to accomplish the most basic aspect of file IO. The idea that other features would not come out as a consequence is unfortunately necessary. People would rather have something that works reliably than something with tons of broken features. Heaven forbid the new model of toaster lacks a laser light show because they had to go back fix the issue of it not actually making toast.
Bumping this up again , this issue comes up too often in the context of developing in vstudio especially for web/mobile development. Instead of blanket must fix everywhere , please take a single usecase and figure out how to make it work. The customer below working in node is an excellent place to start. I used to PM at msft and am well aware of the top down planning done there, its time to change or lose more developers to the droid / ios world.
Matthew Evans commented
Constantly hitting this, projects and namespaces having to be adjusted to accommodate a problem a decade old. Leaving it just means more resources in the future will be required to address it.
Mohit Raghav commented
:( it would be good to remove this limitation!
I have been working on node almost exclusively on Linux because of this limitation.Tried again with V.S. 2015 and ran into it immediately.
I live on the other side of the lake (Sammamish) from Microsoft and have been working in Linux more and more. I really like Windows but constantly running into these types of issues and Microsofts refusal to fix them is driving me away. I do have to commend them for their contributions to open source along with Google. It also amazes me to see open source people bash Microsoft for being the "Borg" and then haul out a Mac (hypocrisy at its worst).
Why is this problem affecting visual studio and not visual studio code?
William Bosacker commented
@George Mauer: Actually, this and the alternate request, are a good starting point. 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.
George Mauer commented
I'm on this thread so I obviously complained about this too at one point but I want to express both a partial workaround (that doesn't require remapping drives) and some of the reasoning why this might not be the appropriate board to complain about this issue.
First the workaround - at least with regards to deleting long paths. Since nodejs can create long paths (by using the unicode API) it can also delete them. Install the rimraf utility globally and you can use it to delete deep directory trees.
npm install -g rimraf
Now as to what is going on. The Windows team has explained in various locations (http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx) but the gist is that the old Windows API which contains code for things like resolving relative paths is hard coded to this limit and removing it would break many old-school third party dependencies over which Microsoft has no control.
You can bypass the limit however by using the unicode API but then you're stuck re-implementing all the functionality yourself, thus forking it and introducing inconsistencies. In all fairness, Visual Studio is not the appropriate location to do this.
Now I would argue that the .Net file APIs *are absolutely* the appropriate location for this. That would solve a large chunk of Visual Studio's issues as well as Powershell and any application that uses .Net.
And looky look, .Net core is becoming open source....
Seems like pure laziness to just decline the request. Pretty easy problem to solve!
Simple Workaround commented
Every time I encounter this problem I create a directory junction with a short path and reopen the project from there.
It would be great if VS had created the junction from behind the scenes, maybe prompting a window to the users if it might affect them in any way.
Martin S commented
Please prioritize this problem - that's it's hard and requires resources is not an excuse. I'm hitting this limitation daily as a professional developer. It's making developing on windows a pain. I'd never develop on windows unless I had legacy code to deal with, mostly due to this single issue, that's a shame ;(
Robert McKee commented
Fix it already!
R L Vandaveer commented
I ran into the issue my first attempt at working with the Node.js tools for VS.
Was this response from 2013 or 2033? It's a stupid problem.