Implicit architecture targeting not in place for dotnet tool install

[richlander]

The spec talks about implicit RID targeting.

From that doc, these are the implicit RIDs:

• .NET 6: osx-arm64
• .NET 5: osx-x64
• .NET Core 3.1: osx-x64

Not documented, on Windows these would be slightly different:

• .NET 6: win-arm64
• .NET 5: win-arm64
• .NET Core 3.1: win-x64

My environment:

rich@MacBook-Air-M1-2020 app % dotnet --info | grep RID
RID: osx-arm64
rich@MacBook-Air-M1-2020 app % dotnet --version
6.0.100-rc.2.21478.25

This is working, AFAICT, for dotnet run.

rich@MacBook-Air-M1-2020 app % cat app.csproj | grep Target
<TargetFramework>net5.0</TargetFramework>
rich@MacBook-Air-M1-2020 app % dotnet run
/Users/rich/app/app.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Host.osx-x64 with version (= 5.0.11)
/Users/rich/app/app.csproj : error NU1102: - Found 2021 version(s) in dotnet6 [ Nearest version: 6.0.0-alpha.1.20423.5 ]
/Users/rich/app/app.csproj : error NU1102: - Found 62 version(s) in nuget.org [ Nearest version: 6.0.0-preview.1.21102.12 ]
/Users/rich/app/app.csproj : error NU1102: - Found 1 version(s) in internal [ Nearest version: 6.0.0-rc.2.21474.18 ]

The build failed. Fix the build errors and run again.

That's failing, but due to a mismatch in versions available on the feeds I have registered, so NP. The key thing is that the CLI is asking for the osx-x64 package, which is the desired one.

Let's look at dotnet tool install in contrast.

rich@MacBook-Air-M1-2020 app % dotnet tool install -g dotnet-serve
You can invoke the tool using the following command: dotnet-serve
Tool 'dotnet-serve' (version '1.9.71') was successfully installed.
rich@MacBook-Air-M1-2020 app % dotnet-serve 
zsh: killed     dotnet-serve
rich@MacBook-Air-M1-2020 app % codesign -s - ~/.dotnet/tools/dotnet-serve 
rich@MacBook-Air-M1-2020 app % dotnet-serve                              
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '5.0.0' (arm64) was not found.
  - The following frameworks were found:
      6.0.0-rc.2.21470.37 at [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
      6.0.0-rc.2.21475.12 at [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=5.0.0&arch=arm64&rid=osx.11.1-arm64
rich@MacBook-Air-M1-2020 app % 

It is pretty obvious that this isn't a good situation. The user needs to know a-priori that dotnet-serve needs to be installed with -a x64. We can and should do that automatically, matching dotnet run behavior.

[sfoslund]

Spent some time investigating this and the problem is that we don't know what the TFM is. When the --framework option isn't specified we default to trying to get the current TFM (net6.0), meaning we default to arm64. So far looking at the code, I don't know if we're able to get the actual resulting TFM that gets installed. @joeloff did Will give you a tour of the tool code before he left? Do you know if this is possible or not?

[sfoslund]

Discussed offline with @joeloff and we don't think this change is going to be do-able for GA. The fundamental issue here is that we don't know what the TFM for a given tool package is when we're determining the RID, and adding this support will be a big fix. At the moment the RID and app host are resolved before the tool package is installed, but we don't know what the package's TFM is until we have it on disk and can look at the package's metadata. To be able to figure out the TFM we'd have to make some significant and potentially risky changes to tool install logic order and content, including some code that is pretty outdated and messy (example: https://github.com/dotnet/sdk/blob/main/src/Cli/dotnet/ToolPackage/ToolPackageInstaller.cs#L178).

We've come to the conclusion that we aren't comfortable making this change in QB mode for GA, and we'd prefer to make this change in 6.0.2xx due to the risk. This way, we'd also be able to clean up and update some of the old code that would be too risky to touch for 6.0.1xx.

Tagging this issue for team triage to discuss more on Wednesday cc @richlander @marcpopMSFT

[richlander]

In the case of dotnet-serve, there is only one folder in the package, for net5.0. See: https://nuget.info/packages/dotnet-serve/1.9.71

If this change is too risky for 6.0.100, it's fine to target 6.0.200. dotnet test is going to be in a similar boat.

[marcpopMSFT]

Moved to 6.0.2xx. Let's include this in the known issues with the workarounds so we have something to point customers at.

[sfoslund]

Fixed by #22331