'Dotnet tool restore' does not work correctly when NUGET_PACKAGES (global-packages) is set to an alternative location

[da9l]

Issue Title

'dotnet tool restore' does not work correctly when NUGET_PACKAGES (global-packages) is set to an alternative location.

Description

If you set NUGET_PACKAGES to an alternate folder. "D:\cache" on a build agent for instance,

dotnet tool restore # and then directly after
dotnet paket info # or paket <whatever>.

will fail with $lastexitcode=1 and
Run "dotnet tool restore" to make the "paket" command available.

The same error happens for at least two other tools as well. gitversion.tool and dotnet-fsharplint.

Repro steps

See this minimal example: https://github.com/da9l/dotnetpaketProblem_minimalExample/blob/master/readme.md

Expected behavior

it should work.

Actual behavior

fail with $lastexitcode=1 and
Run "dotnet tool restore" to make the "paket" command available.

Known workarounds

Don't set NUGET_PACKAGES to anything non-standard.

[pagebrooks]

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"

[Jacknq]

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

[detoxhby]

Still happens with latest SDK. It makes local tooling unusable for teams as restore cannot be used and developers are forced to reinstall the tools by hand which is something that could be avoided by local tooling manifest usage.

Any reliable workaround for using custom packages path with local tools?

[jespergustinmsft]

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.

[szakib]

We have the same issue.

[slav]

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

[szakib]

The most robust workaround I have found. Assuming Windows, NuGet packages at c:\NuGet, powershell:
if (-Not (Get-Item -Path '$Env:USERPROFILE\.dotnet\toolResolverCache' -Force).LinkType) { Remove-Item -Force -Recurse '$Env:USERPROFILE\.dotnet\toolResolverCache'; New-Item -ItemType Junction -Path '$Env:USERPROFILE\.dotnet\toolResolverCache' -Target 'C:\NuGet' }
You can run this blindly on all build agents or stick it in a group policy object / login script.

[bondarenkod]

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.

You saved my day, thank you!

[iamjplant]

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

[zerovian]

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.

[zerovian]

Seems like we need a way in the nuget.config file (and/or environment varaible) to specify the toolResolverCache location so we can point to a local folder in the same way we can point to a local packages cache.

[iamjplant]

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.

[alexrp]

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.

[reynoldsa]

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.

[molesmoke]

Likewise, I just switched to dev drive and found that dotnet tool restore doesn't work with it...

[baronfel]

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.

[Jacknq]

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.

Quite a challenge to tackle it since its 3 years already...

[klemmchr]

Stumbled upon this after setting up my DevDrive. What is the status on this? Looks like no progress for the past 6 months.

[jeremy-visionaid]

@klemmchr I think everyone's just using the symlink workaround still

[diegosasw]

@klemmchr I think everyone's just using the symlink workaround still

This is a better workaround in my opiniopn #11432 (comment)

[klemmchr]

@klemmchr I think everyone's just using the symlink workaround still

This is a better workaround in my opiniopn #11432 (comment)

That is only a temporary workaround and will not completely resolve the issue.