LongPath support

[0x53A]

The new long path support for Windows 10 CU had to be backed out again, because it failed on lower windows versions.
#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.

[matthid]

#1944 (comment) could work as well.

[NightWatchman]

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.

[0x53A]

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 #1944 (comment) for context.