SDK with net5.0 change fails to restore dotnet repo tools

[ViktorHofer]

See dotnet/runtime#33837 (comment) for more details

Microsoft.DotNet.ToolPackage.ResolverCacheInconsistentException: more than one row for coverlet.console-1.7.0-net5.0-any-coverlet
   at Microsoft.DotNet.ToolPackage.LocalToolsResolverCache.TryGetMatchingRestoredCommand(RestoredCommandIdentifier restoredCommandIdentifier, CacheRow[] cacheTable, RestoredCommand& restoredCommandList)
   at Microsoft.DotNet.ToolPackage.LocalToolsResolverCache.TryLoad(RestoredCommandIdentifier restoredCommandIdentifier, RestoredCommand& restoredCommand)
   at Microsoft.DotNet.Tools.Tool.Restore.ToolRestoreCommand.PackageHasBeenRestored(ToolManifestPackage package, String targetFramework)
   at Microsoft.DotNet.Tools.Tool.Restore.ToolRestoreCommand.InstallPackages(ToolManifestPackage package, Nullable`1 configFile)
   at Microsoft.DotNet.Tools.Tool.Restore.ToolRestoreCommand.<>c__DisplayClass11_0.<Execute>b__0(ToolManifestPackage package)
   at System.Linq.Enumerable.SelectArrayIterator`2.MoveNext()
   at System.Linq.ParallelEnumerable.ToList[TSource](ParallelQuery`1 source)
   at System.Linq.ParallelEnumerable.ToArray[TSource](ParallelQuery`1 source)
   at Microsoft.DotNet.Tools.Tool.Restore.ToolRestoreCommand.Execute()
   at Microsoft.DotNet.Cli.DotNetTopLevelCommandBase.RunCommand(String[] args)
   at Microsoft.DotNet.Tools.Tool.ToolCommand.Run(String[] args)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)

cc @dsplaisted @rrelyea @wli3

[rrelyea]

do we have a repro tools project, or scenario that can repro this?
Right now, i think sdk team (@wli3 @dsplaisted) should take first look here.

[ViktorHofer]

Trying to work on a repro, we at least have a binlog if that helps:

Restore.zip

[ViktorHofer]

@wli3 I'm unsure if we really clean the %userprofile% directory for every CI run. I believe we should definitely set DOTNET_CLI_HOME to a temporary location for CI runs and I assumed we already do.

@Chrisboh @MattGal are we cleaning the %userprofile% (more precisely the %userprofile%.nuget) directory for every CI run or is that cached?

[wli3]

I am looking for the root cause

[markwilkie]

Adding @ChadNedzlek and @ilyas1974

[ChadNedzlek]

Helix doesn't clean any folders outside of the HELIX_CORRELATION_ROOT and HELIX_WORKITEM_ROOT. It's possible that the Azure Pipelines agent would clean those directories, but it's highly unlikely, they usually work hard to redirect anything that would normally write there to some other, controlled, location. And arbitrarily deleting everything in that directory would be dangerous.

[wli3]

The repro is:

run tool restore with 5.0.0-preview3
run tool restore with 5.0.0-preview1
run tool restore with 5.0.0-preview3

Here is what happens.
first restore cache add line:
{"Version":"1.7.0","TargetFramework":"net5.0","RuntimeIdentifier":"any","Name":"coverlet","Runner":"dotnet","PathToExecutable":"C:\Users\wul\.nuget\packages\coverlet.console\1.7.0\tools/netcoreapp2.2/any/coverlet.console.dll"}

second restore, since preview 1 don't know what is net5.0, an extra cache line is added
{"Version":"1.7.0","TargetFramework":"netcore5.0","RuntimeIdentifier":"any","Name":"coverlet","Runner":"dotnet","PathToExecutable":"C:\Users\wul\.nuget\packages\coverlet.console\1.7.0\tools/netcoreapp2.2/any/coverlet.console.dll"}

3rd restore, preview 3 knows netcore5.0 == net5.0, so the select query get more than one result. And it errors out since this should not happen.

This error is a special case that only happens once when we rename netcore5.0 to net5.0. And we don't have back compact requirement between previews. I suggest no product fix. Instead we should override DOTNET_CLI_HOME to ensure no shared state between CI runs. @ViktorHofer

[MattGal]

Helix doesn't clean any folders outside of the HELIX_CORRELATION_ROOT and HELIX_WORKITEM_ROOT. It's possible that the Azure Pipelines agent would clean those directories, but it's highly unlikely, they usually work hard to redirect anything that would normally write there to some other, controlled, location. And arbitrarily deleting everything in that directory would be dangerous.

True, I'd just add the scripts here always will ensure that the build workspace is either clean or new if it can't delete the older ones; builds can and should always install things like this inside the workspace if possible as this will get automatically cleaned up and not require any special knowledge of using Helix folders.