[release/5.0] Add support for repo-defined runtime.json for shared framework build

[ericstj]

Customer Impact

Framework dependent applications running on new RIDs cannot load RID-specific assets. New RIDs are not well supported.

Testing

Built shared framework. TODO: Manually inspect 5.x shared frameworks.

Risk

Minimal. This should result in behavior similar to 6.0 build and should restore a flow similar to what we had in 3.x.

Fixes dotnet/runtime#50739

Note this is a PR to 5.0 servicing, not sure when it is OK to merge it. Once merged and ingested into dotnet/runtime we should validate it's working correctly by examining the framework deps files for RIDs added in servicing.

I used the same property used in 6.0 which points to the repo's copy of runtime.json. It should be defined here:
https://github.com/dotnet/runtime/blob/74905e767eb7b971636310965b66bf5dfd6a3545/eng/liveBuilds.targets#L203-L206
https://github.com/dotnet/runtime/blob/74905e767eb7b971636310965b66bf5dfd6a3545/Directory.Build.props#L74

[Anipik]

do we need this in 6.0 as well ?

[safern]

do we need this in 6.0 as well ?

I believe that's already there with the new shared framework sdk work done by @jkoritzinsky

[ericstj]

do we need this in 6.0 as well ?

No, in 6.0 it only happens this way already due to the refactoring done in the shared framework SDK:

arcade/src/Microsoft.DotNet.SharedFramework.Sdk/src/GenerateSharedFrameworkDepsFile.cs

Lines 101 to 105 in e97027c

	RuntimeGraph runtimeGraph = JsonRuntimeFormat.ReadRuntimeGraph(RuntimeIdentifierGraph);
	runtimeFallbackGraph = 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.

I chose parameter/property names to match that.

[mmitche]

This can be merged at any point, just need to ensure we only trigger the arcade dependency once branches open for 5.0.10.

[jamshedd]

Approved for September.

[ericstj]

@mmitche are these linux failures expected for arcade? Seems like it might be an infra issue, could block getting good test results during arcade servicing. I'm not too worried with this change, who should follow up?

Error response from daemon: pull access denied for microsoft/dotnet-buildtools-prereqs, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
##[warning]Docker pull failed with exit code 1, back off 2.147 seconds before retry.

[ericstj]

Seems like a new failure since this one passed earlier this month: https://dev.azure.com/dnceng/public/_build/results?buildId=1226879&view=results

[riarenas]

@ericstj that error looks like we're missing cfe12e6 in the 5.x branch.

[ericstj]

/azp run arcade-ci

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).