(minor) regression in vmr building on unknown rid

[tmds]

When the runtime repo is built it outputs two packages for Microsoft.NETCore.App.Crossgen2. One is for the target rid, and the other matches the rid of the SDK that is used to do the build.

So if you start out with the linux-x64 Microsoft SDK and build on Fedora 41, you end up with linux-x64 and fedora.f41-x64 for Microsoft.NETCore.App.Crossgen2.

If you use that SDK again on Fedora 41, you end up with fedora.f41-x64 only.

And if you use that SDK on Fedora 42, the build fails to compile because the SDK doesn't know the Fedora 42 rid while compiling aspnetcore:

  /home/tester/workdir/dotnet/src/aspnetcore/src/Framework/App.Runtime/src/Microsoft.AspNetCore.App.Runtime.Composite.sfxproj : error NU1100: Unable to resolve 'Microsoft.NETCore.App.Crossgen2.linux-x64

For .NET 9, Private.SourceBuilt.Artifacts only has a non-portable Crossgen2 and the aspnetcore build had no problem using it.

This doesn't impact common scenarios.

It would be nice if we can have it working again similar to .NET 9, where there is only a single Microsoft.NETCore.App.Crossgen2 in Private.SourceBuilt.Artifacts which is for the non-portable rid.

Also for ILCompiler, there is a linux-x64 package that gets included: runtime.linux-x64.Microsoft.DotNet.ILCompiler.<version>.nupkg whereas for 9.0, there is only a package for the non-portable rid.

cc @jkoritzinsky @ViktorHofer

[tmds]

My preference would be for the non-portable builds to not produce any packages (in Private.SourceBuilt.Artifacts) that have a portable rid in their name. That makes it more clear that portable Microsoft assets are not leaking into the build.

That said...

@jkoritzinsky is there a change we can make to runtime build so it produces a portably named package also when the SDK used was a non-portable one? Some substitution of NETCoreSdkRuntimeIdentifier to NETCoreSdkPortableRuntimeIdentifier?

That would fix this regression.

[jkoritzinsky]

We can definitely figure out a mechanism to filter out the "host-targeting" packages from Private.SourceBuilt.Artifacts.

The other scenario I think I'd need a little more info (maybe a binlog) to figure out exactly what's failing and why.