The `any` RID fallback for framework dependent, RID-agnostic tools does not include all required assets

[andrewlock]

Describe the bug

#49499 highlighted the need for any to provide a "framework agnostic" fallback when building RID-specific tools. However, the any package that is built does not contain all of the assets it should, in particular, it does not contain all the native binaries needed to support any platform.

To Reproduce

I was testing this out with a simple tool by adding a native dependency (SQLite) to @baronfel's https://github.com/baronfel/multi-rid-tool project, and doing RID-specific dotnet pack (the program doesn't matter, it can be hello world)

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>netcoreapp3.1;net5.0;net6.0;net7.0;net8.0;net9.0</TargetFrameworks>
    <LangVersion>latest</LangVersion>
    <PackAsTool>true</PackAsTool>
    <ToolCommandName>sayhello</ToolCommandName>
    <PackageId>sayhello</PackageId>
    <PackageVersion>1.0.0</PackageVersion>
  </PropertyGroup>
  
  <!-- specific -->
  <PropertyGroup>
    <PublishSelfContained>false</PublishSelfContained>
    <RuntimeIdentifiers>linux-x64;linux-arm64;win-x64;win-arm64;any</RuntimeIdentifiers>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Spectre.Console" Version="0.50.0" />
    <PackageReference Include="Microsoft.Data.Sqlite" Version="9.0.8" />
  </ItemGroup>
</Project>

Running dotnet pack on the project produces the expected RID-specific packages, e.g.

However, the any package contains none of the native assets:

Whereas it should (I believe) contain all of them:

Exceptions (if any)

N/A

Further technical details

details of dotnet --info

> dotnet --info
.NET SDK:
 Version:           10.0.100-preview.7.25380.108
 Commit:            30000d883e
 Workload version:  10.0.100-manifests.8bb6be96
 MSBuild version:   17.15.0-preview-25380-108+30000d883

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26100
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.100-preview.7.25380.108\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
Workloads are configured to install and update using workload versions, but none were found. Run "dotnet workload restore" to install a workload version.

Host:
  Version:      10.0.0-preview.7.25380.108
  Architecture: x64
  Commit:       30000d883e

.NET SDKs installed:
  9.0.301 [C:\Program Files\dotnet\sdk]
  9.0.304 [C:\Program Files\dotnet\sdk]
  10.0.100-preview.7.25380.108 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.19 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.0-preview.7.25380.108 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.19 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.0-preview.7.25380.108 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 8.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.19 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.0-preview.7.25380.108 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  D:\repos\blog-examples\MultiRid\global.json

- command line

[baronfel]

Thanks for trying out the new feature @andrewlock - I repro and agree with your analysis. We'll dig in an see how to mitigate, hopefully for RC2.

[baronfel]

This one is pretty core. Here's what a publish of a RIDless version of your sample app looks like:

And here's the any RID:

The RuntimeTargetsCopyLocalItems are missing entirely.

[baronfel]

@dsplaisted took a look at this plan and we are going to go forward with making ResolvePackageAssets behave like it does for RID-less builds when RID=any.

[andrewlock]

Just to clarify @baronfel, is there any first-class story for combining any with the self-contained/self-contained trimmed/AOT packages? They don't seem to work either, but it's not clear to me whether they're expected to (I can understand why they wouldn't, but if not, seems like a bit of a gap?)

[baronfel]

No - any by definition needs a runtime. It is the equivalent of a completely RID-less, platform-agnostic application. It cannot be self contained, trimmed, or AOT-d - all of which embed the runtime (or various slices of it) into your packaged application.

[andrewlock]

That totally makes sense, but it does still seem like a gap? The same way that you want the any package for the framework dependent, platform specific case, it seems like you have the exact same use cases for the self contained and do trimmed cases? I.e. I want my tool to work anywhere, but I've optimised certain cases?

Anyway, happy to open a separate issue about it, thanks!

EDIT: to be clear, I'm suggesting a framework dependent, non platform specific fallback package would be a nice option to have, instead of having to try to do that manually by hacking a way to it!

[baronfel]

I feel like there's a fundamental gap here - the thing you want cannot currently be satisfied by the .NET toolchain in any configuration that I'm aware of. When you say "I want my tool to work anywhere, but I've optimised certain cases", to my mind that's the explicit goal of these RID-specific packages (the "optimized certain cases" part) with the RID-agnostic any fallback (the "want my tool to work anywhere" part). The SDK tooling picks whichever one you've provided that works best on the user's system.

EDIT: to be clear, I'm suggesting a framework dependent, non platform specific fallback package would be a nice option to have, instead of having to try to do that manually by hacking a way to it!

I'm not clear on this - to my mind the any RID is that framework-dependent, non-platform-specific fallback package? I'm curious to know where the feeling of having to hack a way to it might be.