dotnet tool install uses current runtime's dotnet.exe and not current dotnet.exe to restore tool
See original GitHub issueIf multilevel lookup is enabled (current default), the sdk can be running on a runtime from a different directory than the dotnet.exe that launched the sdk command. When tool install shells out to dotnet restore, it picks the dotnet.exe next to the runtime that is being used and not the dotnet.exe that hosted the tool install command.
Steps to reproduce
- Have some 2.1.x runtime newer than 2.1.0 installed to global c:\program files\dotnet
- Have SDK 2.1.300 unzipped to c:\example
set PATH=c:\example;%PATH%
set DOTNET_MULTILEVEL_LOOKUP=
mkdir repro && cd repro
dotnet new global.json --sdk-version 2.1.300
dotnet -d tool install -g some-tool
Expected behavior
Restore uses the dotnet.exe from c:\example and succeeds
Actual behavior
Restore uses the dotnet.exe from Program Files, and then fails to find the 2.1.300 SDK pinned in global.json
D:\repro>dotnet -d tool install -g some-tool
Telemetry is: Enabled
Running C:\Program Files\dotnet\dotnet.exe restore C:\Users\nicholg\AppData\Local\Temp\a4mqhtjd.cnm\restore.csproj --runtime any -property:BaseIntermediateOutputPath=C:\Users\nicholg\.dotnet\tools\.store\.stage\ujrqo0tp.121 -verbosity:quiet
Process ID: 12388
A compatible installed dotnet SDK for global.json version: [2.1.300] from [D:\repro\global.json] was not found
Please install the [2.1.300] SDK or update [D:\repro\global.json] with an installed dotnet SDK:
2.1.507 [C:\Program Files\dotnet\sdk]
2.1.604 [C:\Program Files\dotnet\sdk]
2.1.800-preview-009677 [C:\Program Files\dotnet\sdk]
2.2.104 [C:\Program Files\dotnet\sdk]
2.2.204 [C:\Program Files\dotnet\sdk]
2.2.400-preview-010195 [C:\Program Files\dotnet\sdk]
3.0.100-preview5-011568 [C:\Program Files\dotnet\sdk]
The tool package could not be restored.
Tool 'some-tool' failed to install. This failure may have been caused by:
* You are attempting to install a preview release and did not use the --version option to specify the version.
* A package by this name was found, but it was not a .NET Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:12 (9 by maintainers)
Top Results From Across the Web
Troubleshoot .NET tool usage issues
Discover the common issues when running .NET tools and possible solutions.
Read more >dotnet tool install command - .NET CLI
The dotnet tool install command provides a way for you to install .NET tools on your machine. To use the command, you specify...
Read more >dotnet restore command - .NET CLI
Learn how to restore dependencies and project-specific tools with the dotnet restore command.
Read more >dotnet build command - .NET CLI
The dotnet build command builds a project and all of its dependencies. ... To disable implicit restore, use the --no-restore option.
Read more >c# - Error installing dotnet tool package because "it is not ...
I built my project successfully, but dotnet.exe on my computer still behaviors very strange and unstable, I mean sometimes project still not ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Ya, switching to
UseDotNet@2
allows me to remove my workaround since it’s already applied within the task.I do not set that variable. But in checking the YML again, I’m not using the
@1
version of the task either. I’m using@0
. 🤦♂