`dotnet tool install` doesn't understand multi-arch systems or TFM requirements

A user of the .NET global tool vsmac-cli reported the following host error when trying to use the tool after installing it.

% vsmac
A fatal error occurred. The required library libhostfxr.dylib could not be found.
If this is a self-contained application, that library should exist in [/Users/[USER]/.dotnet/tools/.store/vsmac-cli/0.2.0/vsmac-cli/0.2.0/tools/net5.0/any/].
If this is a framework-dependent application, install the runtime in the global location [/usr/local/share/dotnet/x64] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [/etc/dotnet].

The .NET runtime can be found at:
- https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=osx.12-x64&apphost_version=6.0.3

This error occurred because the app is framework dependent and the end user does not have the required framework installed. This is likely a common scenario for end users, yet the message is needlessly complex, with implementation details (libhostfxr) and irrelevant information (self-contained vs shared) that appears to be targeted at the developer of the app. This provided URL also appears to be incorrect, as the app’s manifest does not allow it to be run with 6.x.

I would suggest that the error be more specifically targeted at helping end users understand the problem and resolve it e.g. something like

This application depends on version 5.0.x of the shared .NET runtime, which is not installed on this machine.
The latest compatible version of the runtime can be found at https://aka.ms/dotnet-runtime?version=5.0&rollforward=minor&rid=osx.12-x64

Perhaps dotnet-tool could also detect the missing runtime and prompt users to install it upfront when installing the tool.

[dhduvall]

I ran into this (or some subset of it) today. I think some of this is new information; I hope it’s useful.

I got into the situation originally with SDK 6.0.300 (6.0.5 runtime), but it’s reproducible with the latest as of today—7.0.200 (7.0.3 runtime). I’m on an M1 Mac (arm64), and this was my experience:

$ dotnet --info
[ see bottom of comment ]

$ dotnet tool install --global coverlet.console
Skipping NuGet package signature verification.
You can invoke the tool using the following command: coverlet
Tool 'coverlet.console' (version '3.2.0') was successfully installed.

$ coverlet -h
You must install .NET to run this application.

App: /Users/duvall/.dotnet/tools/coverlet
Architecture: x64
App host version: 7.0.3
.NET location: Not found

Learn about runtime installation:
https://aka.ms/dotnet/app-launch-failed

Download the .NET runtime:
https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=osx.13-x64&apphost_version=7.0.3

The instructions at the app-launch-failed URL just told me to install the .NET runtime, which I’d already done. I’d used the installer, so it should have been in the expected place, etc.

It took me a while to notice the x64 in that output, and realize that it wasn’t complaining about the version (though when I first ran it, I didn’t have 7.0 installed, so it was probably complaining about that, too), but the architecture.

What I didn’t see mentioned in the discussion above was the --arch flag to dotnet install:

$ dotnet tool uninstall --global coverlet.console
Tool 'coverlet.console' (version '3.2.0') was successfully uninstalled.

$ dotnet tool install --global --arch arm64 coverlet.console
Skipping NuGet package signature verification.
You can invoke the tool using the following command: coverlet
Tool 'coverlet.console' (version '3.2.0') was successfully installed.

$ coverlet -h
Cross platform .NET Core code coverage tool 3.2.0.0

Usage: coverlet [options] <<ASSEMBLY|DIRECTORY>>
[ ... ]

The original discussion here is from some time ago, and I’m sure things have changed a bit since then, but it seems like much of the discussion has been about whether the tool is available at all for ARM64. But that certainly doesn’t seem to be my problem. Instead, it looks like even when there is a choice, the installer makes the wrong one.

dotnet --info

.NET SDK:
 Version:   7.0.200
 Commit:    534117727b

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.1
 OS Platform: Darwin
 RID:         osx.13-arm64
 Base Path:   /usr/local/share/dotnet/sdk/7.0.200/

Host:
  Version:      7.0.3
  Architecture: arm64
  Commit:       0a2bda10e8

.NET SDKs installed:
  6.0.406 [/usr/local/share/dotnet/sdk]
  7.0.200 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.14 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.14 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

[vitek-karas]

@akoeplinger I think the problem with global tools should not be solved in the host - host is for all apps, lot of the above problems are relatively specific to global tools. Also things like roll-forward are very focused on developers, the host needs to target “normal users” - so anything more complicated than “Please visit this URL” is probably too much (and yes, the current experience is unfortunately already too much).

I think the core of the problem is that dotnet tool install makes several assumptions which are problematic to say the least:

• The tool is applicable to the local machine (what if that tool is simply not meant to run on Linux… ???)
• The tool can run on any version of .NET (maybe with some minimum version)
  • Basically assumes that the tool has rollforward set to Major
  • Assumes that the tool will never break on new .NET
• The tool can run on the architecture/OS of the current machine - this goes to the problem with RIDs and so on, but in short, what if the tool simply doesn’t want to support some combination (maybe because it can’t)
• The tool better not want custom executable (like for example powershell), otherwise it’s a mess

I personally don’t know much about the dotnet tool install to be honest, but lot of the above assumptions seem to be part of the system in some way or form. And some of them are simply not viable for the tools we want to use this for.

I think the solution to this would start by having a clear declaration of the requirements for a given tool and the dotnet tool install validating such requirements. This can be .NET version, architecture and many more. Ideally the dotnet tool install would also be able to fix some of these - like installing new/older version of the runtime, installing different architecture, …

Basically dotnet tool install tries to act a little like a package manager - without implementing most of the complexities which come with it.