Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
'Dotnet tool restore' does not work correctly when NUGET_PACKAGES (global-packages) is set to an alternative location
See original GitHub issueIssue 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.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:19
- Comments:14
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
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
toolResolverCacheseems to fix the issue. On linux it’s at~/.dotnet/toolResolverCache