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
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!
This response is a ******* joke, frankly. You know it's a problem: fix it.
It's 2014 and we still have to work around bullsh*t contraints like this. So basically if we add a service reference to our project we have to jump through hoops to publish it. You took away the setup projects from VS and now you expect us to use this broken thing instead?
How to follow this suggestion?
Please stop neglecting this. This is a real spoiler when working with large and deep domain structures. I do understand that this would require a large amount of Work.
But come on... It's 2014... You know "Cloud-first, Mobile-first" and everything. Let's not be stopped by some "Maximum Path Length Limitation" from the last Century.
Epic failure! So when things gets difficult the VS team bails out. And it's really a sorry excuse to target extensions and tools as a prime reason. I've lost count of how many extesions that's been abandoned from one VS release to the next. I'm sure the makers of extensions will update their extension to a new ecosystem if they are serious and comitted enough.
It is an old and ridiculous limitation that regularly costs me time (and money). I try and circumvent by always moving VS default folders to one level down of a folder with a short name but this issue still bites often enough to be dealt with. I understand all the tools, etc argument but if you (MS) don't start to take a lead on this it will always be with us and this is one thing your customers want fixed above many many other problems and so called new features (which most us don't use or want).
Please rethink your approach to this.
George Mauer commented
Soooo....what's the solution for node_modules directories which can get very deeply nested?
As a matter of fact, what's the solution for any package management system that uses private dependencies stored in subdirectories?
Super DUper commented
The character limitation is not only an annoyance it is an actual problem that limits windows' ability to be used in many working applications and makes people waste time circumventing this stupid limitation.
We don't care much for the 'innovations' MS is working on as they tend to be not really that great, even in the deeper technical sense, most people only want the system to work as its supposed to (how many times have I had to hold a long conversation convincing people that Windows 8 is not garbage...). MS needs to fix this limitation as it is insanely ridiculous.
Ask your family members what they think about this limitation.
This is the year 2014 and maybe some old software could be broken... Maybe. Listen to your costumers, move your ***.
Simon J commented
This is such a frustrating limitation. Lost count of the number of hours we've lost rationalising a large number of enterprise projects and branches in an attempt to overcome this problem.
I have just tested Windows Server 10 technical preview build 9481 (which is Windows version 6.4) and I am astonished and disappointed to say this limitation still exists in the operating system so there is no chance of it being fixed in Visual Studio or TFS.
Here is hoping this is going to be resolved before the final release however this is such a low level thing you would think it would be in the preview.
This is nothing short of pathetic
Geez. Despicable. I know you're being honest, Will, but this is just disgusting. So much effort put in by Microsoft over the past decade on "innovation" that few people wanted, but we had crammed down our throats anyway. Even more effort trying to repeal that "innovation" in many cases. Meanwhile, probably just about every business of even small size and complexity (easily millions of them) has encountered this problem, and it's been there forever.
It's not like WE have some sort of problem; we're trying to make things more organized in our company by having logical, comprehensible information arrangement. How many tens of billions of dollars have been been cumulatively wasted by companies trying to figure out workarounds to this ONE problem? How many more billions of dollars have been wasted in inefficiency working with the kludges necessary to get around this ONE problem? I'm not exaggerating these numbers; some simple conservative math can tell you have many collective hours are probably spent on this.
***** the "innovations." They're pushed to everything as well. Instead, start NOW on pushing out the fix to this long time problem, and then advertise that the "new character limit" will make file organization a million times easier. Yes, it's going to be a huge undertaking, but THAT'S the "innovation" we all want in the next Windows, not a bunch of changes to things that already worked or backtracking and corrections of mistakes in judgement.
Rafael Colucci commented
That´s just sad. I think that someone should get fired. Will Buik; you should have said that customers dont matter to Microsoft since the questions has more than 3k votes. You guys keep doing things no one cares instead of fixing bugs in things that were already delivered to customers. You better say that there is no one qualified to fix this at Microsoft.
And who the DUMB just declined this post...
Well these people are the result of the HOLY TRUTH that "Microsoft can't do anything correctly"
Well we all understand that Microsoft cannot do anything correct !! including Visual Studio, and all
"architectural change across different products and features including Visual Studio, TFS, MSBuild and the .NET Framework.".