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.
We’ve removed the limitation from the BCL for the basic file manipulation functionality (CRUD). You can find more details here:
Program Manager .NET
Foster Sanders commented
I had the same problem. I didn´t know what to do so I searched on the internet for some solutions.
And I read about [b]Long Path Tool[/b], which is a great tool in these type of cases. :o
It worked really well. Hope it works for you too :p
The fix applies to applications written to use it. Visual Studio 2015 is an application that currently does not make use of it, though you can write applications with Visual Studio 2015 that do. Visual Studio 2017 supports it, but no one has said if Visual Studio 2015 will be patched to use it.
Mike Clark commented
I'll also point out that I am only using .NET Core projects and still experience this issue from within VS.
Mike Clark commented
Unless I just completely misunderstood this fix, this is not working for me. I am using Visual Studio 2015 with Update 3, on Windows 10 with "Enable Win32 Long Paths" enabled. When I try to add a project whose final path exceeds 260 characters I receive the "The length of the full path for the solution, project or item blah blah blah" error. I can workaround this by manually renaming the project and it's path to the desired name, and adding it back to the solution. However, this is an insanely clunky mess and seems completely unnecessary. Obviously, as Visual Studio has no issues actually working with a project (that I can see anyways) there should be no reason for the UI to prevent me from doing this right in File > New Project.
I'm having this issue now with a brand new Xamarin project on Visual Studio 2015 update 3 etc.
@Kub, on WIndows 10? It is very unlikely that support will ever be added to Windows 7 or earlier, and doubtful that they will add it to Windows 8. If it's not working on Windows 10, report it at Microsoft Connect.
Not working on Visual Studio 2017 RC.
It's still not working with NET Framework 4.6.2 and Visual Studio Express 2013. How can i fix that problem right now?
@Steve as of the release of .NET Framework 4.6.2, all applications using it will have the ability to use it, if correctly configured to do so. However, it will take some time for applications to be patched/upgraded to support their use. The best guess is that by the end of 2016, those applications that are going to be patched, will be. All new applications should support log file paths out of the box, if they target:
- .NET Framework 4.6.2 or later.
- .NET Core (any RTM version)
- Use the Win32 API directly.
As for TFS 2013, it has already entered EOL, so you may be forced to upgrade to TFS 2015 in order to use long path names when it becomes available. Since Windows 7 (any version) and earlier, or Windows 2008 server (any version) or earlier, are all in the EOL phase, or already phased out. It is very unlikely that they will be updated to support long paths via the Windows UI, whereas the Windows 10 UI is currently being tested with long path name support.
How would this work for say, building applications in TFS 2013? Would you some how be able to opt in by configuring the build agents to support long paths?
You can use Long Path Tool if you are lazy and you want the software to do a the work instead
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.
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..
@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.