Update KnownRuntimePack as part of updating KnownFrameworkReference

[pranavkm]

No description provided.

[wtgodbe]

https://dev.azure.com/dnceng/public/_build/results?buildId=1590349&view=results tests this workaround against the commits from #39853 pre-SDK update

[dougbu]

It's not clear what you intend @pranavkm. As-is, the change does nothing because the %(LatestRuntimeFrameworkVersion) metadata is updated earlier in exactly the same way.

https://github.com/dotnet/aspnetcore/pull/39965/files#diff-9fb67cbc0a7ba3b793455ec41e7f36e1d019d5152674d669551810b308510d37R44-R45

[pranavkm]

@dougbu the targets currently update KnownFrameworkReference but not KnownRuntimePacks. In a Blazor WASM app, the latter is used to resolve the rid-specific runtime pack (Microsoft.NETCore.App.Mono.browser-wasm). Screenshot of the build logs before this change:

[dougbu]

Ah, I understand now. Do we need to do this w/ the @(KnownAppHostPack) item for the default Core TFM too❔

[pranavkm]

Further details - the version for KnownRuntimePacks currently comes from the value the SDK bakes in. With a blazor app, it currently compiles using the version of the runtime specified by the targeting park that we override, but runs against the version from the SDK. This is problematic in that we're not testing blazor against new runtime ingestions. Additionally, it also prevents runtime insertions when the targeting pack and the runtime pack don't align. #39853 was a recent example of this.

[pranavkm]

Do we need to do this w/ the @(KnownAppHostPack)

I suppose we should - it's also got the SDK-specified version. That said, I don't know how that package gets used in the build.

[dougbu]

I don't know how that package gets used in the build.

I'm not positive either. I suspect your new commit will primarily affect tests that execute dotnet {something}.

@wtgodbe anything we should be concerned about❔ For example, are there cases where the versions won't align❔ Versions for the app host, runtime pack, and framework reference all match in the couple of SDKs I checked. Just wondering if I'm missing anything in how dotnet/runtime pushes new packages during servicing.

[wtgodbe]

I'm not aware of any reason the runtime versions in an SDK would mismatch across ApphostPack/Runtime pack/Framework Reference - @dsplaisted any corner cases we should be aware of?

[wtgodbe]

Didn't realize components-e2e was the failing job, here's the real test: https://dev.azure.com/dnceng/public/_build/results?buildId=1590790&view=results

[pranavkm]

@dougbu / @wtgodbe good to merge?

[wtgodbe]

Test build worked, merge away

[dsplaisted]

I'm not aware of any reason the runtime versions in an SDK would mismatch across ApphostPack/Runtime pack/Framework Reference - @dsplaisted any corner cases we should be aware of?

I think those versions will always be the same. This looks good to me.

[ghost]

Hi @dsplaisted. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.