.NET Core executables fail if .NET Core is not installed in default location

[natemcmaster]

Steps to reproduce

Download .NET Core CLI to $env:USERPROFILE/.dotnet/x64 and install a global tool

$env:PATH="$env:USERPROFILE/.dotnet/x64;$env:PATH"
dotnet-install.ps1 -Version 2.1.300-preview3-008646 -InstallDir $env:USERPROFILE/.dotnet/x64
dotnet-install.ps1 -Runtime aspnetcore -Version 2.1.0-preview2-final -InstallDir $env:USERPROFILE/.dotnet/x64
dotnet tool install -g dotnet-serve
dotnet-serve

Expected behavior

The generated shim dotnet-serve.exe should find and use the dotnet on PATH to launch the global tool.

Actual behavior

If no .NET Core is installed in C:\Program Files\dotnet

PS > dotnet-serve
A fatal error occurred, the required library hostfxr.dll could not be found.
If this is a self-contained application, that library should exist in [C:\Users\namc\.dotnet\tools\.store\dotnet-serve\0.3.0\dotnet-serve\0.3.0\tools\netcoreapp2.1\any\].
If this is a framework-dependent application, install the runtime in the default location [C:\Program Files\dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location.

If .NET Core is installed in C:\Program Files\dotnet, but doesn't have the right shared framework version

PS> $env:COREHOST_TRACE=1
PS> dotnet-serve
Tracing enabled
--- Invoked apphost [version: 2.1.0-rc1-26419-02, commit hash: 515f580aa000600da03e81537396d2253b16fa12] main = {
C:\Users\namc\.dotnet\tools\dotnet-serve.exe
}
The managed DLL bound to this executable is: '.store\dotnet-serve\0.3.0\dotnet-serve\0.3.0\tools\netcoreapp2.1\any\dotnet-serve.dll'
Using default installation location [C:\Program Files\dotnet] as runtime location.
Reading fx resolver directory=[C:\Program Files\dotnet\host\fxr]
Considering fxr version=[2.0.5]...
Considering fxr version=[2.0.6]...
Considering fxr version=[2.0.7]...
Detected latest fxr version=[C:\Program Files\dotnet\host\fxr\2.0.7]...
Resolved fxr [C:\Program Files\dotnet\host\fxr\2.0.7\hostfxr.dll]...
Loaded library from C:\Program Files\dotnet\host\fxr\2.0.7\hostfxr.dll
Probed for and did not resolve library symbol ????????????
The required library C:\Program Files\dotnet\host\fxr\2.0.7\hostfxr.dll does not support relative app dll paths.

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.300-preview3-008646
 Commit:    8e01912b36

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16299
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Users\namc\.dotnet\x64\sdk\2.1.300-preview3-008646\

Host (useful for support):
  Version: 2.1.0-rc1-26419-02
  Commit:  515f580aa0

.NET Core SDKs installed:
  2.1.4 [C:\Users\namc\.dotnet\x64\sdk]
  2.1.100 [C:\Program Files\dotnet\sdk]
  2.1.105 [C:\Users\namc\.dotnet\x64\sdk]
  2.1.300-preview2-008530 [C:\Users\namc\.dotnet\x64\sdk]
  2.1.300-preview3-008646 [C:\Users\namc\.dotnet\x64\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0-preview2-30478 [C:\Users\namc\.dotnet\x64\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.0-preview2-final [C:\Users\namc\.dotnet\x64\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.0-rc1-30613 [C:\Users\namc\.dotnet\x64\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0-preview2-final [C:\Users\namc\.dotnet\x64\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.0-rc1-30613 [C:\Users\namc\.dotnet\x64\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.1.5 [C:\Users\namc\.dotnet\x64\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Users\namc\.dotnet\x64\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0-preview2-26406-04 [C:\Users\namc\.dotnet\x64\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0-rc1-26419-02 [C:\Users\namc\.dotnet\x64\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

[natemcmaster]

Possible solution: the apphost should automatically default DOTNET_ROOT to the first dotnet.exe on PATH.

[livarcocc]

This is by design and the decision we made on the host taking many different things in consideration. I believe the dotnet install message will guide you to setting DOTNET_ROOT if your dotnet is not installed in the default location.

[natemcmaster]

My concern about this design is that the error message is not clear when there are some .NET Core runtime installations in C:\Program Files\dotnet, but not the right ones for the global tool. How would a user ever figure this out from this?

PS> dotnet-serve
The required library C:\Program Files\dotnet\host\fxr\2.0.7\hostfxr.dll does not support relative app dll paths.

[livarcocc]

@steveharter is this something that we could improve in the host?

[steveharter]

The error message could be extended to provide more information, but is really a short-term problem since once the hostfxr should be updated (once) it should be good forever for this particular error message.

Possible solution: the apphost should automatically default DOTNET_ROOT to the first dotnet.exe on PATH.

I'd prefer not to start probing %PATH%

[natemcmaster]

I'd prefer not to start probing %PATH%

Can you elaborate? It seems like it would be a better user experience, but want to know why you would rather not.

I was expecting this PATH lookup behavior because it's one we depend on to make Visual Studio work SDKs installed into user-locations. It's also one less variable that we have to set to make CI builds work well. We already have a handful, and the list seems to be ever growing.

[steveharter]

@richlander

Probing %PATH% for dotnet.exe is not intuitive and somewhat error-prone as we can't exactly duplicate what the OS does. That's why we added %DOTNET_ROOT%

[tmds]

I filed the same issue for Linux: https://github.com/dotnet/core-setup/issues/4078. I have the same expectation as @natemcmaster: dotnet should be searched on PATH.
For source-build Red Hat, Fedora and CentOS, dotnet is not installed at the 'default' location. So tools fail out-of-the-box 😕

CC @eerhardt @dleeapho @omajid

An alternative solution (https://github.com/dotnet/core-setup/issues/4078#issuecomment-384653329) is to allow source-build to specify the 'default' location. That would fix the source-build case, but not @natemcmaster's case. This would still require setting DOTNET_ROOT. Perhaps we can use this fallback order: DOTNET_ROOT, PATH probing, hard-coded path.

A pseudo Unix implementation for finding the root via PATH:

segments = split PATH by ':'
foreach segment
  dotnet_path = concat(segment, "/dotnet")
  if (stat(dotnet_path, out dotnet_stat) == SUCCESS && dotnet_stat.isExecutable)
     if (realpath(dotnet_path, out dotnet_real) == SUCCESS)
        return dirname(dotnet_real)
return null

[dasMulli]

Aren't there other things already looking for dotnet.exe on the %PATH%?
MSBuildSdkResolver AFAIK

This could lead to situations where dotnet-mytool and dotnet mytool may end up choosing a different runtime. The question here is what a user would expect..

[tmds]

Independent of implementation, a user expects this to work:

$ dotnet tool install -g dotnet-serve
$ dotnet-serve

[eerhardt]

The issue I have with probing the %PATH% env var is that the %PATH% variable is used to locate executables to run. In this case, we've already found the executable to run. The dotnet-serve executable was located and loaded and started executing. The %PATH% environment variable served its purpose.

Now, the dotnet-serve executable needs to load some more libraries (ex. coreclr, System.Private.CoreLib, etc). Why should the PATH variable be involved with how to locate more libraries? It's main purpose is for locating executables to be executed.

In my opinion it conflates the job/purpose of the PATH environment variable. It can also lead to other side effects, such as having 2 "dotnet hives" installed on your machine. One on the PATH, and one not. Now if you invoke /path/to/dotnet tool install -g dotnet-serve and then run dotnet-serve it won't necessarily use the same "dotnet hive" you used to install it.

That's why we introduced a new environment variable that serves a single purpose - locating the "dotnet hive".

[tmds]

@eerhardt what do you think about this order then: DOTNET_ROOT, hard-coded path, PATH probing.

• where host currently fails with an error message, it will try to probe the PATH.
• and for use-cases where there is a system install, but you want to use another dotnet hive you need to set DOTNET_ROOT.

[livarcocc]

@steveharter @richlander

[natemcmaster]

A agree with what @tmds said. It was my expectation that after dotnet tool install, dotnet serve would use the same dotnet used to install the tool. I think many users will expect this.

To @eerhardt's points:

Why should the PATH variable be involved with how to locate more libraries? It's main purpose is for locating executables to be executed.

I understand the engineering purity of this argument, but think there is another compelling point to consider. PATH probing is consistent with how the rest of the product behaves. Over the last few years, we have been teaching people that you can install .NET Core into a custom location. If you put it on PATH first, Visual Studio, VS Code, MSBuild.exe, and the command line will use that custom install location. The current behavior of global tools breaks from this pattern. And from what I'm hearing, the reasons for breaking from that pattern seem to be narrowly focused on what the apphost should do, not on the behavior of the .NET Core product as a whole.

Now if you invoke /path/to/dotnet tool install -g dotnet-serve and then run dotnet-serve it won't necessarily use the same "dotnet hive" you used to install it.

I agree with you here. I would not expect dotnet-serve to find /path/to/dotnet. That said, I'm not asking this. I'm asking for PATH probing.

Let me be completely clear why this is so maddening to me. The majority of .NET Core tools today are written so they can be invoked as dotnet <command> (that's a subject for another conversation, but it's the reality of the current world.) If I have C:\custom\dotnet.exe first on PATH, when invoking dotnet <command>, the "dotnet" used is C:\custom\dotnet.exe, but the CLI will launch <command> part in a new context that ignores C:\custom\. If nothing else, please set DOTNET_ROOT from the CLI to the current location so any subprocesses launched by the CLI will resolve to the same dotnet.exe.

[steveharter]

Concerns

1. The OS does all of the %PATH% probing today, so this would be a new area for us to consider. We can't guarentee we follow the same rules as how the OS uses %PATH%
2. Performance: if there are 20 folders in %PATH% before we find a hit (or miss) we would be probing\reading 20 folders and possibly doing a stat to ensure executable...
3. We would need to ensure this is not a security\hijack concern

That said, I agree that the scenario is real and proposed solution has merit. We did consider this during the design phase, I can PM you that link. However, that discussion for %PATH% was not considered as a last-resort fallback at the time; instead it was competing with %DOTNET_ROOT% as the primary mechanism.