I just want to share my findings; that I managed to work around it by deleting the %USERPROFILE%\.dotnet\toolResolverCache folder before running dotnet tool restore.

deleting toolResolverCache seems to fix the issue. On linux it’s at ~/.dotnet/toolResolverCache

This might have renewed relevance given the release in Windows’ Dev channel preview of Dev Drive, where an explicitly called-out use case is to redirect package caches there. I recently hit this myself and got around it with the workaround, but when this hits GA more developers may encounter this.

We ran into this issue as well. As a workaround, we had to create a symbolic link from the standard location to our customized location so that the dotnet cli would behave properly.

> mklink /J "C:\Users\username\.nuget\packages" "X:\CustomPath\.nuget\packages"

Redirecting globalPackagesFolder is actually quite important for some scenarios, e.g. testing custom MSBuild SDKs. It’s not really reasonable to tell people they might have to nuke a cache in their home directory to work on my project.

This is on our list to tackle - it’s one of the things that we have more control over now that we’re not doing an behind-the-scenes dotnet restore on a specially-formatted project file. We’re in more direct control of the tool package download so can respond to changes like this more directly.

This workaround does seem to be sufficient for now. Are there plans to fix this issue, however?

hi, same issue here, its connected to v 1.0.1 , if i install 0.50 it works, if i upgrade it fails always with

Run “dotnet tool restore” to make the “dotnet-script” command available.

win 10 x64 sdks installed 2.1.811 [C:\Program Files\dotnet\sdk] 3.1.301 [C:\Program Files\dotnet\sdk] 5.0.100 [C:\Program Files\dotnet\sdk]

nuget

 <config>
    <add key="repositoryPath" value="./../pckgs" />
  </config>

PS D:\work\dev\vuecore> dotnet tool uninstall dotnet-script
Tool 'dotnet-script' was successfully uninstalled and removed from manifest file D:\work\dev\vuecore\.config\dotnet-tools.json.
You can invoke the tool from this directory using the following commands: 'dotnet tool run dotnet-script' 
work\dev\vuecore\.config\dotnet-tools.json.
PS D:\work\dev\vuecore> dotnet script test.csx
Run "dotnet tool restore" to make the "dotnet-script" command available.
PS D:\work\dev\vuecore> dotnet tool restore
Tool 'dotnet-script' (version '1.0.1') was restored. Available commands: dotnet-script

Restore was successful.
PS D:\work\dev\vuecore> dotnet script test.csx
Run "dotnet tool restore" to make the "dotnet-script" command available.

how to reproduce install the tool globally, uninstall, install and uninstall locally, repeat locally, doesnt work

Same problem for us. We run tests in parallel and those tests do project restores which often have the same set of files that need to be downloaded from a nuget feed. We put in the override in the nuget.config to make each test use a separate packages cache to avoid the concurrency problem. Because of this issue: NuGet/Home#8129

But now that we’re trying to incorporate use of tools, the restore fails on some machines. Deleting the ‘toolResolverCache’ folder for the user helps, but that’s terrible in a concurrent test environment where multiple tests need the tool. And we also do not want to install stuff globally.

Like you say, it’s pretty rough in a concurrent test environment. It’s causing some headaches.

Same problem for us. We run tests in parallel and those tests do project restores which often have the same set of files that need to be downloaded from a nuget feed. We put in the override in the nuget.config to make each test use a separate packages cache to avoid the concurrency problem. Because of this issue: https://github.com/NuGet/Home/issues/8129

But now that we’re trying to incorporate use of tools, the restore fails on some machines. Deleting the ‘toolResolverCache’ folder for the user helps, but that’s terrible in a concurrent test environment where multiple tests need the tool. And we also do not want to install stuff globally.