plugins_cache needs shorter path to work well

[zarenner]

In microsoft/azure-pipelines-tasks#9446, @maboulianne, @OneCyrus, and @sveinungf all reported an issue with NuGet that appears likely to be due to plugin_cache path lengths being too long (260+ characters).

Please see that issue for the full context, but the relevant part:

2019-01-29T12:56:32.0548084Z System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Windows\ServiceProfiles\NetworkService\AppData\Local\NuGet\plugins-cache\7dfd0fa0c00db55241517876f045626154b6f02c$CredentialProvider.Microsoft.exe\https_comerco.pkgs.visualstudio.com_packaging_ea8caa50-9cf8-4ed7-b410-5bca3b71ec1c_nuget_v3_index.json.dat-new'.
2019-01-29T12:56:32.0548131Z at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
2019-01-29T12:56:32.0548220Z at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
2019-01-29T12:56:32.0548267Z at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
2019-01-29T12:56:32.0548438Z at NuGet.Protocol.Plugins.PluginCacheEntry.d__20.MoveNext()
2019-01-29T12:56:32.0548476Z --- End of stack trace from previous location where exception was thrown --

I see that there are already generally related GitHub issues such as #3324.

However, this specific issue is especially bad since the "DirectoryNotFoundException: Could not find a part of the path" doesn't hint at the path length being the issue. That's more a .NET issue than a NuGet issue IMO, but it's still a confusing experience for our customers. It's also more likely here to exceed 260 characters here since the plugin_cache paths contain essentially the entire URL, the plugin filename, etc and thus are long.

Even if NuGet cannot support long paths, could it at least emit a better error message here indicating the issue?

[nkolev92]

The cache not being discovered should be handled more gracefully. It should not be failing restore completely.
Potentially we need to investigate shortening the generated paths.

This could go multiple ways, but the goal should be to make the whole thing more robust.

//cc @rrelyea

[rrelyea]

i would like to think if this is being run on win10 box opting into longpaths support from windows (which we support elsewhere in our codebase), that it would work well.

yes, if somebody hadn't opted in, and the longpath causes a failure, having a good error with options for user would be great. NUXXXX?

[nkolev92]

i would like to think if this is being run on win10 box opting into longpaths support from windows (which we support elsewhere in our codebase), that it would work well.

@zarenner Are long paths enabled on the average build machine?
I think the versions are Win 10 anniversary or later.

[zarenner]

I have no idea for our hosted agents. @chrisrpatterson?
The initial report in microsoft/azure-pipelines-tasks#9446 was on Server 2016.

[chrispat]

All of the hosted machines are Win 2016 or older right now. For the Visual Studio 2019 images we will be rolling out machines with Win 2019 as the os.