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
Mia Lee commented
This is one the most irritating problems ever encountered by me after my wife! LOL!
Jokes apart, when I try to copy files with path names longer than 255 character, Windows prompts error to me. I had to solve this problem ASAP. After searching a lot I found GS Richcopy 360 works best for these problems. I can rename files, move them delete them! But the features list doesn't stop there only. Some of my favorite features include Some of my favorite features include long path name support which is really important when copying large files, 100% multi threaded file transfer (as the company claims, you can witness the boost in transfer speed yourself), pre scheduled file transfer, email notification when the transfer is done, NTFS support, and many more exciting features. I am currently using the enterprise version of it. Try it hope it helps you all!
gabriel aga commented
Try long Path Tool
If you follow the directions at the URL posted above:
AND, are working on Windows 10 (or Windows Server 2016) with the proper profile setting set, it will work. If you are working on any other version of Windows, or have not turned on the profile setting, it will not work.
P.S. There is only one person that says anything about "Long Path Tool", and that is the author. He regularly SPAMs advertisements for his tool that look like normal posts from different people. Including every single post on this thread.
Welcome to the ******** that is Windows. Even after all these years we are still ******.
Corey Van Sickle commented
I just updated a WPF application to .Net 4.7 and I still cannot get IO.File.Exists to return true on any path longer than 260 characters, even when prepending such a path with "\\?\" (as noted in the .Net 4.6.2 announcement). I'm guessing that I'm not actually missing anything, because I haven't seen any comments actually saying that this is working. It would be nice to actually get a solution to this rather than just an announcement falsely claiming that it works.
I'm having this problem as well. The big green title says "Completed", but it's not. :( I've been scouring the internet for a long time and everybody keeps saying "Long Path Tool", but that's a work around AFAIC. If the issues is deep within Windows, then I feel the MSBuild system should do all it can to alleviate these problems to support modern web development tools. For example, one of my node packages (grunt css minifier) has ~8 - 10 nested "node_modules" in it. I'm tinkering with the csproj "beforebuild" and "afterbuild" tasks to try and fix it. Would love to see a clean solution to this problem!!
I can tell that the issue is not fixed in VS 2017 when it comes to C++ projects.
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.