LongPath support
The new long path support for Windows 10 CU had to be backed out again, because it failed on lower windows versions. https://github.com/fsprojects/Paket/pull/1944
Another option would be to use libraries like https://github.com/peteraritchie/LongPath or https://github.com/alphaleonis/AlphaFS, which replace the System.IO namespace. These have the added advantage that they should also work on all Windows versions, not only Windows 10 CU.
https://github.com/fsprojects/Paket/pull/1944#issuecomment-316843735 could work as well.
Just a quick note to express interest in getting this fixed. I'm having a real hard time using GitHub github actions with a self-hosted runner now because github actions checks out my code into .../_work/long-repo-name/long-repo-name and when paket goes to restore NuGet dependencies I get paths like C:\actions-runner\_work\long-repo-name\long-repo-name\packages\test\runtime.opensuse.13.2-x64.runtime.native.System.Security.Cryptography.OpenSsl\runtime.opensuse.13.2-x64.runtime.native.system.security.cryptography.openssl.4.3.3.nupkg which paket can't handle.
Hi Eric, there's a workaround: use an external manifest together with the app config switch.
Create a new file paket.exe.manifest with the following content (and place it next to paket.exe)
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
</windowsSettings>
</application>
Add the required switch to Paket.exe.config:
<!-- see https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/ -->
<AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false;Switch.System.IO.BlockLongPaths=false" />
</runtime>
</configuration>
Increase the last-modified timestamp of paket.exe or reboot because windows caches the existence or absence of a manifest.
See https://github.com/fsprojects/Paket/pull/1944#issuecomment-611646702 for context.