dotnet tool install uses current runtime's dotnet.exe and not current dotnet.exe to restore tool

If 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

1. Have some 2.1.x runtime newer than 2.1.0 installed to global c:\program files\dotnet
2. Have SDK 2.1.300 unzipped to c:\example
3. set PATH=c:\example;%PATH%
4. set DOTNET_MULTILEVEL_LOOKUP=
5. mkdir repro && cd repro
6. dotnet new global.json --sdk-version 2.1.300
7. 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.

[AArnott]

Ya, switching to UseDotNet@2 allows me to remove my workaround since it’s already applied within the task.

[AArnott]

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. 🤦‍♂