[Bug]: Windows Only - nuget install fails with misleading error "Could not find a part of the path" instead of 260 / 248 character error

[jkasten2]

NuGet Product Used

NuGet.exe

Product Version

NuGet.exe 6.2.1

Worked before?

No response

Impact

It's more difficult to complete my work

Repro Steps & Context

One-Line Summary

Nuget does not support paths over 260 / 248 characters on Windows per issue #3324, however it should reliability tell the developer this is the issue.

Details

Given issue #3324 won't be fixed anytime soon and how often this limit is hit having good error messages is critical for developers to understand what the root issue when it is hit. While Nuget sometimes displays the following details when the 260 / 248 Windows path limit is reached it does NOT always do this:

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.
WARNING: Please enbale long file path support in local group policy. Fore more details, please refer to https://aka.ms/nuget-long-path.

The factor seems to be is nuget doesn't consider longer paths and file names in the nuget package itself. It seems it may use part of the name in the calculation if the warning is shown but if it gets this wrong you get a confusing message like this:

Could not find a part of the path 'C:\mypath\somepackge\somelongpath\somefile.something\'

Steps to reproduce

I broke this down into two scenarios where a this "good" error message doesn't show when it should.

Steps to reproduce - Case 1 - Common Package with long project path

This one makes note of the case where we get a "bad" error message for a very common library Newtonsoft.Json but a less common very long pathed project.

Run the following:

nuget install Newtonsoft.Json -OutputDirectory C:\tmp\sommelongpath_gpath_12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789A -Version 13.0.1

And observe the error:

WARNING: Install failed. Rolling back...
Executing nuget actions took 165 ms
Could not find a part of the path 'C:\tmp\sommelongpath_gpath_12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789A\Newtonsoft.Json.13.0.1'.

However if you remove just 1 character from the path you get an expected error:
Run the following:

nuget install Newtonsoft.Json -OutputDirectory C:\tmp\sommelongpath_gpath_12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789A -Version 13.0.1

Gives you an understandable error.

WARNING: Install failed. Rolling back...
Executing nuget actions took 164 ms
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.
WARNING: Please enbale long file path support in local group policy. Fore more details, please refer to https://aka.ms/nuget-long-path.

Steps to reproduce - Case 2 - Less common package that has long contents

This one makes note of the case where we get a "bad" error message for a less common library OneSignalSDK.Xamarin.

• Background on why this package's paths are so long is that Xamarin allows remote building on iOS from Windows but iOS requires a lot of nested paths to support all build targets for iOS.

Run the following:

nuget install OneSignalSDK.Xamarin -OutputDirectory C:\tmp\some_resonable_path_length_123456789\ -Version 4.1.0

Gives you a confusing error about a the first file that just happens to go over the 260 Windows limit:

WARNING: Install failed. Rolling back...
Executing nuget actions took 358 ms
Could not find a part of the path 'C:\tmp\some_resonable_path_length_123456789\OneSignalSDK.Xamarin.4.1.0\content\OneSignalSDK.Xamarin.iOS.resources\OneSignalExtension.xcframework\ios-arm64_i386_x86_64-simulator\OneSignalExtension.framework\Headers\OneSignalNotificationServiceExtensionHandler.h'.

Verbose Logs

No response

[erdembayar]

I can repro this. I feel it's duplicate of #3324
Let's keep it open for now until discussion, this one is asking for warning other one is actual long path support, it looks we used to have long name warning in the past not sure why it doesn't show anymore.

@jkasten2
I was able to make it work after enabling long file support.

Here is how I enabled long file support, probably you don't need both of below steps, just 1 could be suffice. My case I did both, and it works.

1. Press Win + R keys on your keyboard and type regedit then press Enter. Registry Editor will be opened.
   Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem.
   Edit LongPathsEnabled and set it to 1.

2. Press Win + R keys on your keyboard and type gpedit.msc then press Enter. Group Policy Editor will be opened.
   Go to Local Computer Policy -> Computer Configuration -> Administrative Templates -> System -> Filesystem, then enable the Enable Win32 long paths option.

3. Restart your machine.

Please let me know if you have any other question.

[jkasten2]

@erdembayar Thanks for the quick reply!

This issue's scope

I am focusing this issue to a nuget bug where the developer using nuget doesn't always get the over 260 character warning when they should:

One-Line Summary

Nuget does not support paths over 260 / 248 characters on Windows per issue #3324, however it should reliability tell the developer this is the issue.

Since it seems like #3324 won't be fixed for a while so I believe it is important to make sure nuget gives the correct error.

Other documentation note

1. Press Win + R keys on your keyboard and type regedit then press Enter. Registry Editor will be opened.
   Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem.
   Edit LongPathsEnabled and set it to 1.

Would be good to add that registry option to https://aka.ms/nuget-long-path, as it only covers the Group Policy Editor option. 😄

[brunck]

Setting the long path support in the registry and the group policy doesn't seem to make any difference if you build inside of Visual Studio (2022).

[scriptBoris]

@erdembayar no worked. Windows 11 22H2

[sandrocirlini]

no work.... sames error

[Possibility555]

Still having this issue, LongPathsEnabled does not fix it.

[anafletcher88]

I wanted review for LongPath Tool? has anyone used it?