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
This is ridiculous, it's VS itself that adds most of the characters, this is frustrating. What's the point in developing new features if the old ones are broken???
Anthony Brien commented
If the OS allows us to have file names and folder hierarchy of arbitrary length, functions that reference those files shouldn't have a limitation. We're not in 1993.
I think that the fix should at the minimum be done in the .Net Framework. I think that we can all leave with the limitations in MS products but we should at least be able to support long paths in products that we are building for our customers.
Yap, dummies from MS think that is too cool to use subst or 8.3 fnames.
Almost all companies with large solutions meets this issue. But true MS way "it is to hard to fix, eat it as it is, bustards", and we need to fix path length, directory names, file names, use 8.3 fnames and so on.
MS - you idiots, again.
what a joke, this limitation has been biting us in the azz for over a decade and the least MS could have done was to start removing the limitation from their product upgrades which in turn would eventually resolve the issue as a whole.
The real reason this isn't fixed is because it doesn't attract more users.
By the time you stumble on this limitation, it's too late - you've already committed!
Microsoft strikes again.
Hey guess what guys...this issue is so entrenched in MS products, you will actually run into the same issue if you try to delete the same files from your computer. On Win 7 here, and $path strings are too long for the recycle bin. To top off the issue, it doesn't even give you an option to skip the files and it just fails.
In the interest of delivering the most value to our customers, this should be sorted!!
I used PathTooDeep. And was very pleased with its performance. Long Path Tool is awesome to get rid on your long path files. Good luck!
This is the sort of thing that happens when you have a poor design from the start. So you're basically telling your user ship to buzz off. Very nice.
How about actually fixing .NET so that it properly supports Windows filepaths. ie. It is quite easy to create a file (with a long path) that .NET applications are unable to open. Try it if you don't believe me.
Bye, Microsoft! commented
This is a joke.
Charging people lots of money for the software and not even getting such a simple thing to work.
That says it all regarding the quality of microsoft products.
I quit commented
Microsoft own TFS, they own SQL Server, MSBuild, Visual Studio, .NET, even the feking OS! They have full control of the source code and the engineers yet they're unable to provide an adequate solution to a problem that they caused.
Where there are no open source solutions such a show-stopping limitation like this - and at an infinate fraction of the price!
It's bad enough having this bug in the first place, but insulting our intelligence by saying it can only be fixed "at the expense of many other features and innovation" - Yeh, no sh!t? Welcome to the real world of software engineering!
I just wish you would fix bugs at the expense of other features - that nobody even wants! And innovation?? If only you could just do a good job at copying, you wouldn't get a quarter of the complaints on here!
Sorry, Microsoft - but YOU are the cancer of the industry.
VS is dead commented
"fixing it requires a large and complicated architectural change across different products and features"
To fix an artificial character limit??
If you're telling the truth, then you have some severely **** developers!
The fact this limit even exists shows how short-sighted your developers are. I thought 640k ought to be enough for anybody?
Every week I lose more and more confidence in Microsoft - when will I ever learn..?
Johannes Totz commented
As many others have said, and let me repeat it dear microsoft: get the basic functionality right first! then start dreaming up random features (that nobody wants).
we are down to things like c:\a and c:\b because otherwise the compiler will ***** up finding header files in the hierarchy. It will also crash because of some buffer overflow.
makes the whole thing pointless. time to move on, i guess...
Bob Scarborough commented
Dear General Motors; I have a problem with your new model car. The steering wheel can turn right but not left. This makes the car next to impossible to drive.
Dear Customer: Yes we've had lots of complaints about that problem. Unfortunately, fixing it requires complicated re-engineering of the design. Dedicating resources to fix this would come at the expense of many other cool new features such as our magnificent new sound system, smart phone integration, and the new on-demand video player.
Our recommendation is that you avoid driving and enjoy the fabulous new user experience you get from just sitting in the car.
If you must drive, simply avoid routes that require you to turn left.
Ian Johnson commented
Absolutely appalling answer Will Buik,
All of this innovation you speak of is nothing we want. I've written many an app for WinRT it's absolutely horrid (read what your WPF community says about WinRT). You've completely left huge sections of developers a drift in the name of progress (Silverlight anyone).
Yet thousands of developers have come to this site to complain about an absolutely ridiculous 260 limit and your response is it's not in the best interest of the developers.
Stop thinking you know what we need and actually listen to what we are telling you. I guarantee you will produce a better product that works for us ... the developers. You know the people that pay you money to use your products ....
William Bosacker commented
No offense Will, but the majority of the "... many other features and innovation." that you are referring to, none of us asked for. Many of us have told you to get your head out of your ***** before creating the **** that you have currently given us. The only good thing that has happened in the past year is that Steve Ballmer was fired!
This is an absolute asinine answer worthy of typical bureaucrats. Even if we take your advice and try and shorten the names on the local machine, there is no way to remap that particular branch in TFS to the new location on the local machine. I don’t understand why Visual Source Safe was replaced by this infantile system. Not only the functionality we enjoyed with VSS is not there, but a solution to the problem is not there.
If you put a limitation on the local path to 260 chars, the same limitation should be put on the TFS side too, unless you allow us to remap a branch in TFS to a shorter path on the local machine.
Can we get a developer, who really understands the issue, to participate in the conversation rather than some public relation person (no offence intended)? This is a real problem that cost us major time lost and we need real solution. The response we received here is simply not acceptable.