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
Anthony Rogan commented
I use Clickonce to deploy applications to my customers. With about 150 characters of Clickonce app directory prepended (see below), my application direcory name sizes suddenly become 110 characters limitation. Totally unacceptable Microsoft.
William Bosacker commented
On the .NET VLOG for Thursday, June 23, 2016, it was announced that .NET Framework 4.6.2 has the ability to use long path names and the extended syntax. .NET Core has had this functionality since last fall (2015). They also go on to say that the Windows Team is working on the issue for Windows itself.
What does this mean? NTFS has supported long path names (up to ~32768 characters) since XP was first released, but only via the Win32API and by using extended path names. .NET was never given access to this, until now. Windows has always had access to this since XP, but never used it. I would guess that Windows will have full access to long paths before the end of 2016. Once you have .NET Framework 4.6.2 installed on a machine, PowerShell will immediately have access to long path names as well.
I have The Following Issue in VIsual Studio:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
Please Could Someone Help me to solve this issue.
Or Can Someone Suggest me a Idea to Increase the FIlepath legth from 260 to More than 350 or more as we Wish..Because My FileName is Of Length 245..
William Bosacker commented
@Diogo, this site is out dated and stale. FYI, Microsoft has already fixed this issue in .NET Core, which released yesterday, and it should be fully supported by all products within a year. It took them less than 2 days to fix the issue, and your argument is a little silly, 36^255? REALLY?
Diogo Paim commented
I'm with MS with this decision, threre're many other important things to do, and, let's just think... if you can't have more than 2^32 files in a NTFS File system, why would we need more than 36^255 possibilities of filenames?
For the ones that are still trying to solve this, this workaround helped me:
create a C:\p directory to keep short links to long paths
mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
add C:\p\foo to your path instead of the long path
just adding my 2cents, this should be done.
Brian Hall commented
I'm seeing a theme across MS products here...
Throw in the fact that there are also issues when dealing with NPM packages and you have a deep fundamental problem across pretty much the entire Microsoft product line. I predict that this problem will start to rear its ugly head more and more often across more and more products until it's actually fixed. I personally think this problem is indeed important enough to warrant the resources required to fix it. It's very disappointing to see this kind of approach to this issue.
Frank Kloskowski commented
Declined? Wrong answer Microsoft! Please reconsider your answer and excuses for not addressing this.
weird, I'm dealing with this now, trying to make it work on TFS Build Server.
I bookmarked this site.
I love it.
"Declined - Visual Studio UV Site Admin" 2013 -- Unbelievable answer!!
Currently, one of my tfvc 2013 repositories has several files with paths so long they don't show in any repository browser I use. I only see it in the errors that prevent building as a path too long error. This is unacceptable. Apparently you haven't found a way to deal with this internally, as my issue should never have been released with the TFVC product.
The VS product chain costs a lot of money and this issue has been around for a long time. As a release engineer I have to resolve this issue over and over again. I need improvements that make spending that money worthwhile.
Yes, well, I want to vote for this. Can you please re-open it or should we create a brand new suggestion?
Stijn Spijker commented
This needs to be fixed ASAP, as 255 characters is DOS era, and I'd like to think Microsoft has moved on since then.
It's really disappointing this issue being declined. You should at least consider providing an alternate mechanism that modern apps can invoke, and leave the old compatibility for older apps.
Matthew Kruluts commented
You mean to tell me that Microsoft doesn't implement best standards and have something like the maximum character limit set as a globally defined constant in your projects? Meaning, change it once and every where in the project it updates? I expected better from a company trying to enforce best practices on its users.
Seth Rudesill commented
Can this be fixed now please?
What a bad excuse… makes me cry.
Really wait for fixing it.
Long Wang commented
Well thats stupid, bye windows.
Ok. I've taken a deep breath. Commit the freaking resources! How hard can it be to increase the path length across a handful of products. Sigh.