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

[mhutch]

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.

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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

Author:	mhutch
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[richlander]

@elinor-fung

[filipnavara]

I can agree about the message but you also touched on a different issue - on macOS/ARM the global tools depend on the x64 version of the runtime. That's unintuitive and sometimes even quite harmful (eg. installing dotnet-sos installs extensions for x64 lldb). I suspect it was some last minute change because of signing issues because most .NET 6 previews didn't behave that way. @richlander do you happen to know if there's any issue related to that?

(Acquiring a tool through dotnet tool install would normally imply the runtime is already installed so this would not be an issue in the first place.)

[mhutch]

(Acquiring a tool through dotnet tool install would normally imply the runtime is already installed so this would not be an issue in the first place.)

It implies a runtime is installed, but not necessarily the one required by the tool, which is constrained by its roll-forward policy.

[richlander]

I suspect that this tool is cross the Intel/Apple arch boundary.

My guess is that dotnet tool being run via the Arm64 SDK and you have no x64 installation.

[filipnavara]

It implies a runtime is installed, but not necessarily the one required by the tool, which is constrained by its roll-forward policy.

I am well aware of the roll forward policy. It's customary to set it on dotnet tools.

I suspect that this tool is cross the Intel/Apple arch boundary.

That's my point. Look for example at the dotnet-sos NuGet. It has binaries for osx-arm64 and yet if you run dotnet tool install -g dotnet-sos on ARM64 macOS it will require the x64 runtime and run under it. That was NOT the case of the .NET 6 Previews, it was some late change. I'm just asking whether it's documented or whether there is issue filed for it.

(FWIW the dotnet tools don't distribute the host executable, neither does the vsmac-cli NuGet.)

[agocke]

global tools depend on the x64 version of the runtime.

This is news to me. I don’t think there’s anything at the host level which would constrain this — global tools should be creating the appropriate host for the platform.

The only exception is 3.1/5.0 apps, which don’t have an ARM64 version at all. If this isn’t a 5.0 app it sounds like a bug.

[filipnavara]

The only exception is 3.1/5.0 apps, which don’t have an ARM64 version at all. If this isn’t a 5.0 app it sounds like a bug.

vsmac-cli was likely compiled as net5.0 (by looking at the NuGet content). dotnet-sos which has package version 6.0.x seems to be still compiled against netcore3.1 (for backwards compatibility?). Then again, it has roll forward policy and osx-arm64 binaries, so I don't think the intent was to require x64 runtime.

Note: both packages are compiled as any; vsmac-cli doesn't seem to have the roll-forward policy, dotnet-sos has it.

[agocke]

Roll forward is about version resolution, which happens much later then dotnet tool installation, so that isn’t used to determine installation architecture.

I’ll leave it up to the tool-install team to decide if they want to make roll forward an installation concept as well.

However, for tools with native binaries (which may include SOS) there really isn’t another option — you have to have x64 installed.

[filipnavara]

Roll forward is about version resolution, which happens much later then dotnet tool installation, so that isn’t used to determine installation architecture.

I understand that. However, up until net6.0 GA the behavior was to install the platform specific host with no exceptions. Specifically, no exception for osx-arm64. I understand some reasoning about why the exception was put in place but I haven't seen any discussion about it. Hence why I ask whether it's documented or filed as an issue.

However, for tools with native binaries (which may include SOS) there really isn’t another option — you have to have x64 installed.

The problem is that the tool does contain osx-arm64 native binaries but they are never used with the x64 host. The whole tool is likely still targeting netcoreapp3.1 for backwards compatibility. So on arm64 host it never installs the correct LLDB binaries with the current behavior effectively making it quite useless (apart from a scenario where you use x64 lldb under Rosetta with x64 dotnet binaries running under Rosetta).

[agocke]

does contain osx-arm64 native binaries

This is a broken package. You cannot have OS X ARM64 native assets with a netcoreapp3.1 target in a supported way. FYI @tommcdon

[agocke]

However, up until net6.0 GA the behavior was to install the platform specific host with no exceptions

I didn’t know we installed a host at all pre 6.0. I think installing one now is more of an implementation detail, to cope with multiple architecture deployment. @marcpopMSFT to comment on that

[filipnavara]

This is a broken package.

How is one supposed to make it correct though? Specifically, how is one supposed to produce a global tool that installs on all supported .NET versions (or for simplicity, net5.0 and net6.0) and still use arm64 runtime if running on Apple Silicon Mac? Should the NuGet contain duplicate set of binaries with one of them in the net5.0 directory and the other in net6.0 directory?