NuGet and long file name support

[AndreyAkinshin]

I often have the following exception during restore on Windows:

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.

In the NuGet 2.x API, there is a nice interface IFileSystem. So, I could implement own file system which supports long paths. In the NuGet 3.x API, IFileSystem is legacy; the core logic works with the file system directly via System.IO (see an example).

Is there a workaround which adds the long paths support in NuGet 3.x?

[rrelyea]

We do not yet support long paths in NuGet.
https://channel9.msdn.com/Shows/On-NET/Jeremy-Kuhne-long-path-support has some details on new .net framework support for it. We'd like to support this in the future.

[AndreyAkinshin]

@rrelyea, why did you drop the IFileSystem approach? We worked with NuGet 2.x + long paths for a long time. But we can't do it anymore because there is no IFileSystem in NuGet 3.x.

[nerumo]

@rrelyea since Jenkins Branch Pipeline creates horribly long sln root folder names (and they aren't willing/capable to change that, so I can't shorten the path anymore. Is there a another workaround? Will this be addressed in 3.* or in 4?

[rrelyea]

We don't know the exact timeline when we'd be able to do this work. We know if won't fit into NuGet 4.0.0

[NN---]

@nerumo You can try to shorten path with environment variables.

[alpaix]

Bug 389573:[Feedback] Nuget restore fails because path too long

[andymac4182]

Any update on this?
I am running into this with a path that is long because of the system package names. \runtime.opensuse.42.1-x64.runtime.native.system.security.cryptography.openssl\4.3.0\runtime.opensuse.42.1-x64.runtime.native.system.security.cryptography.openssl.4.3.0.nupkg.sha512

[AndreyAkinshin]

Any updates? It's a critical issue for us because we still have to use NuGet 2.x for some features; it's impossible to migrate to NuGet 4.x because of the lack of the long file name support.

[PeterMurdoch]

We tried applying the long file paths GPO to work around this but it was a fail. https://www.saotn.org/wp-content/uploads/2016/10/GPO_Enable_Win32_long_paths_2.png

[damien207]

I am suggesting "Long Path Tool" program that solves path too long issues with simplicity.

[AndreyAkinshin]

Any updates?

[mfilippov]

It is the very painful issue if you restore packages into AppData folder and you have a long username. Some package couldn't be restored. :(

[hypersw]

I'm using core DLLs from nuget for processing packages, and I cannot move to v4 APIs because of this problem.

[NN---]

You can shorten with subst program.
Pretty ugly solution but works.

[Kitwradr]

Please fix this issue, not able to proceed with build because of this issue

[wech71]

[edit] removed my comment because nuget restore produces a correct error message. I used visual studios nuget restore which doesn't ...

[leonluc-dev]

I've recently installed Visual Studio 2022 (which uses NuGet 6.0) but the issue still isn't fully solved yet.
After some testing with NuGet v6.0 this seems to be the current support for long paths:

NuGet related tools that support long paths out of the box

• Dotnet build commands like dotnet restore and dotnet build (only for SDK-style projects)

• Any NuGet tool running on Mac or Linux (including the package manager in Visual Studio for Mac)

NuGet related tools that support long paths after setting the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled registry key value to 1

• nuget.exe command line tool.

• msbuild and dotnet msbuild command line tools.

• Building (not restoring!) projects that use NuGet in Visual Studio 2022

NuGet tools that do not support long paths on Windows at all (no matter the registry setting)

• Installing or restoring packages in Visual Studio 2022

As a workaround I have set the registry key value to 1 and use nuget.exe restore from the command line to restore NuGet packages. Then I build the project using Visual Studio 2022.

[zivkan]

As per the Windows team's docs on supporting long path:

The application manifest must also include the longPathAware element.

The docs also show the XML that needs to be in the manifest for the operating system to allow the process to use long paths. If you look at devenv.exe manifest (for example, open it in Visual Studio itself), you'll see that it doesn't contain the longPathAware element.

As I wrote in my previous comment in this thread, NuGet works on all the command line tools, and the docs I linked here show why it doesn't work in Visual Studio. There's a Visual Studio Developer Community request for this feature, but it has fewer upvotes than this github issue 😞. So, my best suggestion is that giving feedback directly to Visual Studio has a higher probability of influencing change than here to the NuGet team. The process/executable owner has to modify the file to include longPathAware to the manifect, and the NuGet team doesn't own devenv.exe.

[zivkan]

FWIW, I tried editing my machine's devenv.exe to add the longPathAware entry in the manifest. NuGet was able to install packages to paths longer than MAX_PATH, and create the intermediate files in the obj folder that has path longer than MAX_PATH. However, if you try to open a soluion where the full path to a csproj is longer than MAX_PATH, then Visual Studio crashes. There are many components of VS written in C++ (such as SVsSolution, which is what powers Solution Explorer), and all that code would need to be updated.

[dylanbobb]

Still no news on this? We've been reducing our path names as much as possible as a work-around, but this really needs to get fixed! No reason for this to remain open since 2016

[zivkan]

@dylanbobb did you not read my comment directly above yours? NuGet does support long paths (with nuget.exe, dotnet.exe, msbuild.exe), but Visual Studio (devenv.exe) does not.

[dylanbobb]

If the issue really isn't with nuget that's good news! This issue should be closed in that case.

[zivkan]

Although the original request for this issue was about the NuGet SDK, not tooling like msbuild, Visual Studio, nuget.exe, the generic title appears to have caused a number of people to comment on Visual Studio in particular. Therefore, I created a new issue with a more specific title, to gather upvotes:

• [Feature]: Add filesystem abstraction to NuGet SDK #11979

Similar to how MSBuild's "support long paths" issue was closed back in 2019 with the justification that they've done everything in their control to support long paths, and explaining the caveat that just because MSBuild supports long paths doesn't mean that Visual Studio (devenv.exe) does, I'm going to close this for the same reason.

What changed

Back in 2018, nuget.exe was changed to support long path: NuGet/NuGet.Client#2247

For everything else (Visual Studio, MSBuild, other apps using the NuGet SDK), it depends if their executable opts in to Windows' long path support. Refer to Windows' documentation on the long path limitation, and pay special attention to the longPathAware requirement in the application manifest.

Known issues

At the time of writing, Visual Studio (devenv.exe) does not opt into long path support. Therefore, restoring or installing packages in Visual Studio where file names are over 260 characters will not work. There is a Visual Studio Developer Community request to support long paths, which you can upvote: https://developercommunity.visualstudio.com/t/Allow-building-running-and-debugging-a/351628

[senstar-nross]

@zivkan I don't think the fix merged back in 2018 actually does anything. Yes, enabling long path support in the registry seems to fix the NuGet cli but the script as currently checked in does nothing...

Check out line 159 and the -not. That reg key exists and therefore Test-Path returns true...

`$regKeyFileSystem = "HKLM:SYSTEM\CurrentControlSet\Control\FileSystem"
$enableLongPathSupport = "LongPathsEnabled"

if (-not (Test-Path $regKeyFileSystem))
{
Write-Host "Enabling long path support on the build machine"
Set-ItemProperty -Path $regKeyFileSystem -Name $enableLongPathSupport -Value 1
}
`

[zivkan]

@senstar-nross that script is run on NuGet's CI and used to configure the build agent. In other words that script runs on the machine that builds the binaries that we all run on our own machines. The script has nothing to do with the execution of the binaries once built.

As per Windows' documentation, if you have the registry/group policy setting enabled, then any .exe whose application manifest (an xml file embedded inside the .exe) specifies "long paths aware", then NuGet will work fine with paths greater than 260 characters. In 2022 that includes nuget.exe, msbuild and the dotnet cli.

Visual Studio (devenv.exe) does not have the application manifest setting. If you hack the exe, NuGet will successfully extract packages to paths greater than 260 characters, but there are many scenarios/features that will cause VS to crash or fail in other unexpected ways, so this is a very unsupported state that I do not recommend.

[senstar-nross]

@zivkan sorry, yes I realized that after I wrote the comment. The script is still wrong though :)
(The comments about trying to hack devenv is very good to know ... hopefully then next VS will get us there...)