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

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.

Independent of implementation, a user expects this to work:

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

This finds dotnet on PATH and determines DOTNET_ROOT based on that:

export DOTNET_ROOT=$(dirname $(realpath $(which dotnet)))

For those using the snap package, the libhostfxr.so error can be fixed as follows.

export DOTNET_ROOT=/snap/dotnet-sdk/current

Complete configuration for Ubuntu development: /etc/profile.d/04-dotnet-cli-tools.sh

#!/bin/bash
export DOTNET_ROOT=/snap/dotnet-sdk/current
export MSBuildSDKsPath=$DOTNET_ROOT/sdk/$(${DOTNET_ROOT}/dotnet --version)/Sdks
export PATH="${PATH}:${DOTNET_ROOT}"
export PATH="$PATH:$HOME/.dotnet/tools"

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.

The OS does all of the %PATH% probing today

On Linux this is implemented in user-space. For example, corefx implementation is here: https://github.com/dotnet/corefx/blob/9bfa3bd511a6a2152de8192332b0e439917e65e0/src/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs#L480-L498

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…

A lot of things get probed (executable on PATH, libraries on LD_LIBRARY_PATH, …) and we don’t perceive slowness. The earlier on PATH, the sooner the match.

We would need to ensure this is not a security\hijack concern

Using data from PATH is as secure as using data from DOTNET_ROOT.

that discussion for %PATH% was not considered as a last-resort fallback at the time

For the reasons explained by @natemcmaster my preferred order is DOTNET_ROOT, PATH probing, hard-coded path

For source-build, we want to be able to set the hard-coded path. If path probing is implemented, we can rely on that for now. If there is no path probing, we need to make the hard-coded path a setting that can be specified from source-build.

@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%

as a user who just supports dev teams I can’t express how much confusion and frustration dotnet CLI causes. There’s so much mess. We use the dotnet install scripts (https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script) on Linux and making this all work with multiple frameworks/cli versions is just a mess. Please improve so we don’t have to waste time getting seemingly simple things like “dotnet tool” to work.

as a note.

• install .net core sdk 2.1.300-preview2 from unzipping
• add to PATH in front (=> priority), like set PATH=%CD%;%PATH%
• dotnet tool install dotnet-serve --tool-path mybin (install to specific dir)

You can invoke the tool using the following command: dotnet-serve
Tool 'dotnet-serve' (version '0.3.0') was successfully installed.

But both are broken, also direct run of the .exe:

E:\>dotnet serve
The required library C:\Program Files\dotnet\host\fxr\2.0.6\hostfxr.dll does not support startupconfig.json functionality.

E:\>mybin\dotnet-serve.exe
The required library C:\Program Files\dotnet\host\fxr\2.0.6\hostfxr.dll does not support startupconfig.json functionality.

at least the second should work. seetting DOTNET_ROOT fix that.

the dotnet is found on PATH correctly

E:\>where dotnet
c:\dotnetcli\dotnet-sdk-2.1.300-preview2-008530-win-x64\dotnet.exe
C:\Program Files\dotnet\dotnet.exe

but the host\fxr\2.1.0-preview2-26406-04\hostfxr.dll is not probed, so falling back to previous globally installed C:\Program Files\dotnet\host\fxr\2.0.6

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.

I just want to add an anecdote I encountered that caused me a huge amount of confusion, and no amount of dotnet install docs helped because I never ran dotnet install.

I work at a bank and we don’t have admin access to our machines. To not have to deal with the pain that it is getting someone to install .net core 3.0 for me I downloaded the binaries, placed them in c:\users\<name>\dotnet, and added that to my path. I have been successfully doing .net core 2.2 and 3.0 development that way for a while (due to Rider not needing admin to install).

However, I downloaded Linqpad6 (which is a .net core 3.0 application) and it would not run. Running the executable would do absolutely nothing, and trying to dotnet Linqpad6.exe would give an error about hostpolicy.dll not being found (and no mention of any environment variables).

After a back and forth with the Linqpad dev I ended up doing a really round about testing that finally gave me the error above about the DOTNET_ROOT environment variable not being set. Setting this fixed all my issues.

So my point is, this has the potential to really cause confusion for downloaded .net core precompiled binaries and it’s actually very hard to find out that the solution is DOTNET_ROOT.

At a minimum I believe that if DOTNET_ROOT is not set then all executions of dotnet cli should give a warning about this not being set.

I don’t consider one better than the other. I think of them as different scopes for different use-cases. I wish --global was named --user (… naming is hard).

One of the key side-by-side promises of .NET Core was that you could just run an executable from a folder and add things to the PATH, it would be very nice if global tools would follow this approach.

If the PATH was probed as a last resort fallback then it may not be a breaking change after 2.1.300 and could maybe be done for 2.1.400? It would only enable things that would not have worked before anyway and wouldn’t break things that used to work before.

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

Try changing this line to include readlink, which follow the symlink to the actual location of dotnet.

export DOTNET_ROOT="$(dirname "$(readlink "$(command -v dotnet)")")"

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

For those using the snap package, the libhostfxr.so error can be fixed as follows.

export DOTNET_ROOT=/snap/dotnet-sdk/current

Complete configuration for Ubuntu development: /etc/profile.d/04-dotnet-cli-tools.sh

#!/bin/bash
export DOTNET_ROOT=/snap/dotnet-sdk/current
export MSBuildSDKsPath=$DOTNET_ROOT/sdk/$(${DOTNET_ROOT}/dotnet --version)/Sdks
export PATH="${PATH}:${DOTNET_ROOT}"
export PATH="$PATH:$HOME/.dotnet/tools"

I am so lucky to have the awesome people happened to use Ubuntu 18.04 & Snap just as I did. God knows how much time I could spend more on this after a simple automatic update.

This finds dotnet on PATH and determines DOTNET_ROOT based on that:

export DOTNET_ROOT=$(dirname $(realpath $(which dotnet)))

had the same issue while creating a dockerfile for node + pwsh this helped me solvig the issue, so i will post my working result for everyone 😃

FROM node

RUN curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin \
  && /root/.dotnet/dotnet tool install --global PowerShell

#export PATH=/root/.dotnet:/root/.dotnet/tools:$PATH
ENV PATH="/root/.dotnet:/root/.dotnet/tools:${PATH}"
#export DOTNET_ROOT=$(dirname $(realpath $(which dotnet)))
ENV DOTNET_ROOT="/root/.dotnet"

SHELL ["pwsh"]
ENTRYPOINT ["pwsh"]

thx alot

You know GitHub let’s you transfer issues instead of just copying to a new one, right?

Installing a local tool and running it passes on Linux-based microsoft/dotnet docker images but fails on Hosted OSX agents from Azure Pipelines.

The problem here is that on most systems, dotnet will be installed somewhere that would require administrative access (windows admin, superuser permission on *nix) to create directories in. It would also lead to users sharing their tools should they be installed in a global directory.

@welkie the layout under DOTNET_ROOT should be like this. The directory that has the dotnet executable but not the symbol link

.
├── dotnet
├── host
│   └── fxr
├── LICENSE.txt
├── sdk
│   ├── 2.1.300-rc1-008673
│   └── NuGetFallbackFolder
├── shared
│   ├── Microsoft.AspNetCore.All
│   ├── Microsoft.AspNetCore.App
│   └── Microsoft.NETCore.App
└── ThirdPartyNotices.txt

I’m comparing the gobal tools with npm tools. observations:

• -g for npm is independent of users, while -g for dotnet installs into a user folder.
• tools for npm use node that is on PATH

@livarcocc @richlander if you are changing the design of this, please consider doing a https://github.com/dotnet/designs.

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

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.