ProcessFrameworkReferences should add NativeAOT targeting packs for download for all passed in RIDs, not just RuntimeIdentifier

[jkoritzinsky]

Today, ProcessFrameworkReferences only adds the runtime pack for NativeAOT for the RID specified in RuntimeIdentifier. This causes issues when using dotnet restore -r <rid>, as that sets RuntimeIdentifiers, not RuntimeIdentifier. As a result, dotnet restore doesn't restore the NativeAOT runtime pack and then dotnet publish --no-restore -r <rid> will fail in an obscure fashion.

[jevansaks]

We're hitting the same issue. Our pipelines use "nuget restore" to restore solutions because we have mixed vcxproj and csproj, but because we don't pass in Platform or RuntimeIdentifier explicitly, the platform-specific NativeAOT packages don't get restored. Then the build fails with:

microsoft.dotnet.ilcompiler\10.0.0\build\Microsoft.NETCore.Native.Publish.targets(70,5): The PrivateSdkAssemblies ItemGroup is required for _ComputeAssembliesToCompileToNative

Which I suspect is the "obscure fashion" @jkoritzinsky referred to. :)

The projects do have <RuntimeIdentifiers>win-x64;win-arm64</RuntimeIdentifiers> but it doesn't take effect here to restore all the runtime-specific packages.

As a workaround we'll try to pass RuntimeIdentifier through nuget restore or switch to msbuild /t:restore.

[baronfel]

Seems totally reasonable to do this. The runtime packs for frameworks today just have some code that iterates over the passed-in RuntimeIdentifiers and creates+adds the RID-specific packs to the list of PackagesToDownload/PackagesToReference. Something structurally similar would need to be done here for these other kinds of packs. The PR I linked isn't directly related to this request but it does include a) a description of the intended behavior of PFR, which we would want to update with this work, and b) a bunch of smaller, scenario-focused tests for PFR's outputs directly to quickly validate expectations instead of running a bunch of full-SDK-build tests.