Strange fallback RIDs

[TobiasLaving]

Describe the bug

I recently install dotnet on manjaro, a arch like distro, and noticed I have issues running unless I specify runtime. While digging a little with the people on the runtime repo we noticed strange behavior related to the fallback RID. It was suggested I wrote a ticket here as well, as it looked like it was related to the SDK(?)

Below is COREHOST_TRACEFILES
default.txt
arch-x64.txt
linux-x64.txt

If you search for "fallback graph" you will see that the graph is really small for default and arch-x64, while linux-x64 seems to contain all distros(?)

It is my understanding that the fallback graph for arch-x64 should also contain a linux-x64 => [ ... ] which is missing.
Any idea what might have caused it?

To Reproduce

Run COREHOST_TRACE=1 COREHOST_TRACEFILE=linux-x64.txt dotnet run -r linux-x64 and COREHOST_TRACE=1 COREHOST_TRACEFILE=arch-x64.txt dotnet run -r arch-x64 and compare the results in the corefile.

Further technical details

[tobias@tobias-expertbook ~]$ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.100
 Commit:    9e8b04bbff

Runtime Environment:
 OS Name:     manjaro
 OS Version:  
 OS Platform: Linux
 RID:         arch-x64
 Base Path:   /usr/share/dotnet/sdk/6.0.100/

Host (useful for support):
  Version: 6.0.0
  Commit:  4822e3c3aa

.NET SDKs installed:
  6.0.100 [/usr/share/dotnet/sdk]

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

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

[vitek-karas]

Building a self-contained app for RID arch64 produces a .deps.json which has only this as its RID fallback graph:

{
arch-x64 => [
arch, 
linux-x64, 
linux, 
unix-x64, 
unix, 
any, 
base, 
]
}

This is not enough - there should at the very least be a linux-x64 => entry as well. If nothing else, the host will fallback to linux-x64 if the actual RID is not part of the graph (like in the above sample running on manjaro).

Compare this to building an app for RID linux-x64 which produces a large RID fallback graph. I don't know if this comes from the shared framework or if this is part of the SDK logic of building the .deps.json.

[vitek-karas]

For context - the original discussion which found this is here: dotnet/runtime#63338.

[ghost]

Thanks for creating this issue! We believe this issue is related to NuGet tooling, which is maintained by the NuGet team. Thus, we closed this one and encourage you to raise this issue in the NuGet repository instead. Don’t forget to check out NuGet’s contributing guide before submitting an issue!

If you believe this issue was closed out of error, please comment to let us know.

Happy Coding!

[heng-liu]

Hi @vitek-karas , this seems not a NuGet issue. May I know if I could remove the "Area-NuGet" label and reopen it? Thanks!

[vitek-karas]

It's possible this is "from" NuGet (SDK uses NuGet assemblies to deal with some of the complexities around RID graph), but it's as well possible it's not there - we need somebody to investigate.

[vitek-karas]

I think this problem exists pretty much with any RID, it's just not as obvious.
For example, publishing app for ubuntu.14.04-x64 will produce a RID graph which has only 5 nodes:

    "linuxmint.17-x64": [
        ...
    ],
    "linuxmint.17.1-x64": [
       ...
    ],
    "linuxmint.17.2-x64": [
      ....
    ],
    "linuxmint.17.3-x64": [
        ....
    ],
    "ubuntu.14.04-x64": [
      "ubuntu.14.04",
      "ubuntu-x64",
      "ubuntu",
      "debian-x64",
      "debian",
      "linux-x64",
      "linux",
      "unix-x64",
      "unix",
      "any",
      "base"
    ]

Note that it doesn't have fallback paths for linux-x64 either. So running such app on ubuntu.16.04-x64 RID machine would fail the same way as arch-x64 does in this issue. The host would look for ubuntu.16.04-x64 RID, but it's not in the graph, so it would fallback to linux-x64, which is also not in the graph.

The bug is very likely here:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/DependencyContextBuilder.cs

Lines 393 to 399 in c201288

	var runtimeFallbackGraph =
	(_runtimeGraph == null || _runtimeIdentifier == null) ?
	new RuntimeFallbacks[] { } :
	_runtimeGraph.Runtimes
	.Select(runtimeDict => _runtimeGraph.ExpandRuntime(runtimeDict.Key))
	.Where(expansion => expansion.Contains(_runtimeIdentifier))
	.Select(expansion => new RuntimeFallbacks(expansion.First(), expansion.Skip(1))); // ExpandRuntime return runtime itself as first item.

This code filters the original RID graph to only those nodes which mention the RID for which the build is running. But that doesn't produce a complete RID graph, it produces one which works for those nodes which are included. But it will NOT work for nodes which are mentioned, but not listed explicitly, like linux-x64.

We would have to either:

• Hardcode the knowledge of the RIDs the host falls back on and always include those is they are mentioned anywhere in the filtered graph
• Or - construct a transitive closure of the graph from the filter result, by including nodes which are mentioned.

The former approach will produce RID graphs which are going to be just slightly larger than today, but it's a bit fragile.
The latter approach will produce larger RID graphs, but more robust.

There's also the question of how to reconcile this with dotnet/designs#260.

[vitek-karas]

FYI @agocke