-
Notifications
You must be signed in to change notification settings - Fork 446
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add more RuntimeIdentifier information to .NET SDK #9106
Add more RuntimeIdentifier information to .NET SDK #9106
Conversation
Thanks! I was thinking about deriving it after dotnet/runtime#43804, by sharing the supported platform list and resolution of portable and non-portable RIDs list via arcade repo. However, this approach of reliance on RID graph makes it self-sufficient. (I would have never thought about it) 👍 |
Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>
Note that this PR doesn't actually solve the problem of setting a different portable RID in source-build. It simply creates a separate property which can be used to do that. It walks up the RID graph for other reasons, but that alone doesn't tell us which of those RIDs is the right portable RID that we want to use. It might be the same as the |
Looks good. People tend to edit text files, so we should just be aware if the RID file is installed and someone edits it, MSI won't remove the file when it uninstalls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
NETCoreSdkPortableRuntimeIdentifier
to bundled versions. This is the first step to allow us to use a consistent, portable RuntimeIdentifier as the default for the--use-current-runtime
parameter. See --use-current-runtime semantics sdk#14296NETCoreSdkPortableRuntimeIdentifier
, starting from the best match and walking up the tree. This will allow the workload resolver to better handle RID-specific workload packs, without bringing in additional dependencies (NuGet APIs for processing the RID graph as well as .NET Core APIs for getting the current runtime) which would be difficult to run in an MSBuild resolver that has to run on .NET Framework.@mhutch @wli3