dotnet tool install -a arm64 fails on linux-arm64

[mieliespoor]

Describe the bug

dotnet tool install --global <tool-name> --arch arm64 fails reporting that the RID linux-arm64 is invalid.

To Reproduce

1. Create Amazon Linux 2 ARM 64 Instance
2. Install dotnet 6
3. run dotnet tool install --global dotnet-sonarscanner --arch arm64

Exceptions (if any)

Unhandled exception: System.AggregateException: One or more errors occurred. (The runtime identifier linux-arm64 is invalid. Valid runtime identifiers are: win-x64 win-arm64 osx-x64 osx-arm64.)
 ---> Microsoft.DotNet.Cli.Utils.GracefulException: The runtime identifier linux-arm64 is invalid. Valid runtime identifiers are: win-x64 win-arm64 osx-x64 osx-arm64.
   at Microsoft.DotNet.ShellShim.ShellShimTemplateFinder.ResolveAppHostSourceDirectoryAsync(String archOption, NuGetFramework targetFramework, Architecture arch)
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
   at System.Threading.Tasks.Task`1.get_Result()
   at Microsoft.DotNet.Tools.Tool.Install.ToolInstallGlobalOrToolPathCommand.Execute()
   at Microsoft.DotNet.Tools.Tool.Install.ToolInstallCommand.Execute()
   at Microsoft.DotNet.Cli.ToolInstallCommandParser.<>c.<ConstructCommand>b__14_0(ParseResult parseResult)
   at Microsoft.DotNet.Cli.ParseResultCommandHandler.Invoke(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass12_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__18_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseParseDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass8_0.<<UseExceptionHandler>b__0>d.MoveNext()

Further technical details

dotnet --info

dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.302
 Commit:    c857713418

Runtime Environment:
 OS Name:     amzn
 OS Version:  2
 OS Platform: Linux
 RID:         linux-arm64
 Base Path:   /home/bambooagent/dotnet/sdk/6.0.302/

global.json file:
  Not found

Host:
  Version:      6.0.7
  Architecture: arm64
  Commit:       0ec02c8c96

.NET SDKs installed:
  3.1.422 [/home/bambooagent/dotnet/sdk]
  6.0.302 [/home/bambooagent/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.28 [/home/bambooagent/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.7 [/home/bambooagent/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.28 [/home/bambooagent/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.7 [/home/bambooagent/dotnet/shared/Microsoft.NETCore.App]

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

Learn about .NET Runtimes and SDKs:
  https://aka.ms/dotnet/runtimes-sdk-info

• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version

[baronfel]

The set of valid RIDs for the architecture option was chosen in #18832, 16 months ago. I'm unsure the design decision there - @joeloff or @dsplaisted do y'all remember anything about this? Nothing jumps to mind specifically that should block linux RIDs, and we do have host packs for them in NuGet already.

[dsplaisted]

I'm not sure why the list of RuntimeIdentifiers is hardcoded there. Looking at the code it looks like you can't install global tools at all on Linux, though I may be missing something.

Ideally I think the same data that goes in to Microsoft.NETCoreSdk.BundledVersions.props about what RIDs are available for apphosts should be used to drive the tool install too.

[baronfel]

So looking at the .NET 7 apphost declaration in that file,

    <KnownAppHostPack Include="Microsoft.NETCore.App"
                      TargetFramework="net7.0"
                      AppHostPackNamePattern="Microsoft.NETCore.App.Host.**RID**"
                      AppHostPackVersion="7.0.0"
                      AppHostRuntimeIdentifiers="linux-arm;linux-arm64;linux-musl-arm64;linux-musl-x64;linux-x64;osx-x64;rhel.6-x64;tizen.4.0.0-armel;tizen.5.0.0-armel;win-arm;win-arm64;win-x64;win-x86;linux-musl-arm;osx-arm64;linux-s390x;linux-bionic-arm;linux-bionic-arm64;linux-bionic-x64;linux-bionic-x86;linux-ppc64le"
                      ExcludedRuntimeIdentifiers="android"
                      />

We'd ideally be able to a) read this and b) specifically grab the allowed RIDs from AppHostRuntimeIdentifiers here? I can agree with that entirely 👍. Do we have to do more complex RID arithmetic like most-compatible checks? e.g. looking at the tizen entries here there's a 4.0.0 and a 5.0.0.

[marcpopMSFT]

Does this mean that global tools are completely broken on linux? We could add linux-x64 and linux-arm64 to the hardcoded list as a stop gap. As Chet noted, the right solution is getting the known app host pack list out of the bundled targets props file but we don't want to be parsing an msbuild file so potentially we could write out that same data some other way in the installer repo (separate xml file?)

[baronfel]

I just tested with Ubuntu 22.04, .NET SDK 7 from the Microsoft feeds with the fake-cli global tool, and that worked as expected.

> dotnet tool install -g fake-cli
Since you just installed the .NET SDK, you will need to logout or restart your session before running the tool you installed.
You can invoke the tool using the following command: fake
Tool 'fake-cli' (version '5.23.1') was successfully installed.

chethusk@Chet-Desktop:~$ ls /home/chethusk/.dotnet/tools
fake

And that runs as expected. Am I misreading this and we're looking at x64/arm64 emulation code here instead only?

[cn-ml]

I get the same output when cross-building AMD64 / ARM64 Docker images on either host machine architecture, but only when I supply the architecture flag to docker tool install.

[lejsekt]

Hi, just to provide additional context. My use case is to install the correct version (architecture) of the diagnostics tools (e.g. dotnet-counters) in a docker multi-plat build (linux/amd64 and linux/arm64). If I add the arch option to the dotnet tool install command, it fails with the message described above. I also considered downloading the pre-built binary of the tool, but I didn't figure out how to specify the version (https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-counters#install). Thank you for looking at it.

[CharlieDigital]

Came across this same issue today.

• Build environment: osx-arm64
• Runtime environment: linux-x64

When building for linux-arm64, no issues with the tooling. When building for linux-x64, this is problem because the build platform has to be osx-arm64 otherwise the dotnet restore command fails.

However, because the build environment is osx-arm64 it is not possible to run tools like Swashbuckle.Swagger.Cli as my assembly is now targeting linux-x64 which causes errors with tools like dotnet swagger CLI which require loading and running the app to generate the OpenAPI schema since it's trying to load a linux-x64 runtime.

Not sure what the right solution is here, but typing this out helped me understand the issue.

[jwosty]

Not sure if this is the same issue, but I'm running into this issue:

/opt/dotnet/packs/Microsoft.macOS.Sdk/14.2.8078/targets/Xamarin.Shared.Sdk.targets(2027,3): error : The RuntimeIdentifier 'linux-arm64' is invalid.

This is a xamarin app (native macos API), after running dotnet workload restore. It works fine on windows. Just not on Linux. Trying to add a Linux project to my sln.

[flcdrg]

I am building a Docker container that contains a dotnet tool preinstalled. For reasons of efficiency and layer size, I want to only install the runtime bits that are relevant to the container image. Ideally ``--arch linux-x64` would do just that.

For now, my workaround is to install it without specifying --arch and then add a bunch of rm statements to delete all the unwanted runtimes.

[am11]

Ran into the same problem while installing dotnet-sos on linux arm64. If we pass -a arm64, only then it fails. Otherwise dotnet install dotnet-sos --global has no issue. After that lldb debugging works flawlessly on that platform. This indicates that the condition @dsplaisted highlighted was some sort of precautionary measurement which no longer applies.

I think we can simplify that code as follow:

public async Task<string> ResolveAppHostSourceDirectoryAsync(string archOption, NuGetFramework targetFramework, Architecture arch)
{
    string packagePath;
    string? rid;
    if (string.IsNullOrEmpty(archOption))
    {
        packagePath = GetDefaultAppHostSourceDirectory();
    }
    else
    {
        rid = CommonOptions.ResolveRidShorthandOptionsToRuntimeIdentifier(null, archOption);
      packagePath = Path.Combine(_tempDir.Value, "runtimes", rid, "native");
    }

    if (Path.Exists(packagePath))
       return packagePath;

    if (rid is null)
        throw new GracefulException($"Unable to locate {arch} apphost."); // TODO localize

    // download the missing apphost
    var packageId = new PackageId($"microsoft.netcore.app.host.{rid}");
    NuGetVersion packageVersion = null;
    var packagePath = await _nugetPackageDownloader.DownloadPackageAsync(packageId, packageVersion, packageSourceLocation: _packageSourceLocation);
    await _nugetPackageDownloader.ExtractPackageAsync(packagePath, _tempDir);

    return packagePath;
}