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

[nguerrera]

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 filesdotnet
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.

[nguerrera]

Workaround for this is set DOTNET_MULTILEVEL_LOOKUP=0, which is generally recommended in cases where you are trying to use a local SDK over whatever is globally installed anyhow.

[nguerrera]

Surprising code is here:

https://github.com/dotnet/cli/blob/86f8ed535b1dcf0f8790ebe71876794612dba4b7/src/Microsoft.DotNet.Cli.Utils/Muxer.cs#L51-L59

This locates the deps file inside the shared framework we are running against, then walks up to find dotnet.exe.

The expected behavior of using the current dotnet.exe would be to use Process.GetCurrentProcess().MainModule.FileName

[nguerrera]

cc @AArnott

[AArnott]

which is generally recommended in cases where you are trying to use a local SDK over whatever is globally installed anyhow

Do you want to file a bug against the DotNetCoreInstaller task to also set DOTNET_MULTILEVEL_LOOKUP=0 based on this guidance?

[nguerrera]

Do you want to file a bug against the DotNetCoreInstaller task to also set DOTNET_MULTILEVEL_LOOKUP=0 based on this guidance?

@AArnott I went to do that, but it seems they already disable multilevel lookup by default if I'm reading this right:

https://github.com/microsoft/azure-pipelines-tasks/blob/c4dc3ed710b1c36f4756e21eee13c53f14e3f3d2/Tasks/DotNetCoreInstallerV1/dotnetcoreinstaller.ts#L35-L37

Do you have performMultiLevelLookup=true set?

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

[AArnott]

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

[wli3]

Some archaeology, we used typeof before, and changed to existing state due to https://github.com/dotnet/cli/issues/2489 (PR https://github.com/dotnet/cli/pull/2617)

And I am still reading to see if it still applies. It mentioned muxer servicing, but we don't have muxer servicing story. @livarcocc may have context?

[nguerrera]

That change is switching from one way to find the muxer next to current runtime to another. So I don't think that has our answer. Why do we want the muxer of the current runtime and not just the current muxer?

[wli3]

true here

[AArnott]

Actually, my PR linked above to switch to use UseDotNet@2 can't complete because 3 PR builds in a row have failed in the dotnet test step. All tests pass, but dotnet.exe returns a nonzero exit code.

Total tests: 246. Passed: 246. Failed: 0. Skipped: 0.
Test Run Successful.
Test execution time: 10.1186 Seconds
     1>Done Building Project "d:\a\1\s\src\StreamJsonRpc.Tests\StreamJsonRpc.Tests.csproj" (VSTest target(s)) -- FAILED.

Build FAILED.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:02:22.63
##[error]Error: The process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe' failed with exit code 1
##[warning]Invalid results file. Make sure the result format of the file 'd:\a\_temp\VssAdministrator_fv-az48_2019-05-22_04_51_17.trx' matches 'VSTest' test results format.
##[error]Dotnet command failed with non-zero exit code on the following projects : d:\a\1\s\src\StreamJsonRpc.Tests\StreamJsonRpc.Tests.csproj

As you can see it also emits a warning about the .trx file. None of this happens when I use the DotNetCoreInstaller@0 task. I wonder why in the world switching installer tasks would cause this problem.

[wli3]

@AArnott @nguerrera Let move the second issue to https://github.com/dotnet/cli/issues/11406