[release/8.2] Fix RID regression by adding a task that calculates the best matching RID for platform #5807
+310
−10
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Manual backport of #5695 to release/8.2
cc: @eerhardt
Customer Impact
In Aspire, we have always just cross-compiled our Dashbarod and DCP packages for a limited set of RIDs (win-x64, win-x86, win-arm64, linux-x64, linux-arm64, osx-x64, and osx-arm64). When running on platforms that had special RIDs that we weren't cross-compiling for (for example, rhel.8) then we were relying on the SDK's logic to automatically pick the best closest Dashboard and DCP pack for that RID.
However, in Aspire 8.2.0 we removed Dashboard and DCP from the workload and instead just added some sdk targets that were adding these references on the fly, but we were not doing this special matching logic the the SDK used to do and instead we were simply trying to use the current RID, which caused a regression in all of those platforms that have special RIDs which we don't cross-compile for.
In this PR, we are copying the logic that the SDK does for doing that matching, and we are calling it inside of our targets in order to ensure that we are going to get a valid package reference, which will fix the regression in those systems. This has been manually validated in RedHat 8, which was the original report for this regression.
Testing
Automated testing to catch regressions with new versions as well as manual exploratory testing
Risk
Low.
Regression?
yes.
Microsoft Reviewers: Open in CodeFlow