Stop using computed RID for RUNTIME_IDENTIFIER property

[elinor-fung]

Update the property to use the host RID instead of the computed current RID. This is in line with the .NET 8 change for selecting RID-specific assets using the host RID instead of a computed RID.

This also moves updates the shared helper to stop using the computed RID as the current RID - that is moved into the deps resolving, which needs it. Other places use the build-time RID.

This means that RuntimeInformation.RuntimeIdentifier (populated by the RUNTIME_IDENTIFIER property) will return the RID of platform for which the runtime is built, rather than a RID that is computed at runtime (or a fallback if it could not be computed). For example, for a portable build, on Windows 11, it will be win-x64 instead of win10-x64 or on Ubuntu 20.04 linux-x64 instead of ubuntu.20.04-x64.

cc @dsplaisted

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Update the property to use the host RID instead of the computed current RID.

This also moves updates the shared helper to stop using the computed RID as the current RID - that is moved into the deps resolving, which needs it. Other places use the build-time RID.

cc @dsplaisted

Author:	elinor-fung
Assignees:	-
Labels:	area-Host
Milestone:	-

[tmds]

This is a breaking change, right?

RuntimeInformation.RuntimeIdentifier will return linux-{arch} for Microsoft builds. This isn't a useful value as there are other - more appropriate - apis to determine the host is Linux, and to determine the host arch.

That the value is different on source-build .NET (returns the non-portable build rid) is likely to be a source of bugs.

Don't we want to keep RuntimeInformation.RuntimeIdentifier usable as a distro identifier?

[dsplaisted]

This is a breaking change, right?

RuntimeInformation.RuntimeIdentifier will return linux-{arch} for Microsoft builds. This isn't a useful value as there are other - more appropriate - apis to determine the host is Linux, and to determine the host arch.

That the value is different on source-build .NET (returns the non-portable build rid) is likely to be a source of bugs.

Don't we want to keep RuntimeInformation.RuntimeIdentifier usable as a distro identifier?

I don't know the details of the code that's changing and whether this change would return a distro-specific RID for source-built versions of .NET. I believe the right thing would be for it to do so.

We are switching to a trimmed-down RID graph that won't by have distro-specific RIDs, except that source-built versions of the SDK should have RIDs specific to the distros they were built for: dotnet/sdk#34279. However, with the current behavior, RuntimeInformation.RuntimeIdentifier would return RIDs that were not in the trimmed-down RID graph and so they wouldn't be recognized by the SDK. This seems like incorrect behavior and breaks a bunch of the SDK tests.

[elinor-fung]

I thought of RuntimeInformation.RuntimeIdentifier as how the runtime (/host) identifies the platform it is running on (as an opaque value), so in 8+ that would be the platform it was built for. I don't think we have an API that is intended for providing the distro - but I'd think RuntimeInformation.OSDescription (also documented as an opaque value that shouldn't be parsed) would be the differentiator for the actual OS / distro (for displaying).

[agocke]

I thought of RuntimeInformation.RuntimeIdentifier as how the runtime (/host) identifies the platform it is running on

I agree. And I agree with @dsplaisted that the default stated RID should be one that the SDK was built for.

[tmds]

I thought of RuntimeInformation.RuntimeIdentifier as how the runtime (/host) identifies the platform it is running on (as an opaque value), so in 8+ that would be the platform it was built for.

Yes. Since it was introduced this returned a value that identified the Linux distro at runtime.

With this change, it will return a value that identifies the platform the runtime was built for, causing the identifier to be a portable rid for Microsoft builds (e.g. linux-{arch} on all Linux distros) and a different distro version specific rid for source-built builds when running on the same distro.

I don't think we have an API that is intended for providing the distro - but I'd think RuntimeInformation.OSDescription (also documented as an opaque value that shouldn't be parsed) would be the differentiator for the actual OS / distro (for displaying).

Unlike the RuntimeIdentifier, OSDescription wasn't and isn't usable as a 'programmatic' distro identifier and meant only for presentation to the user.

However, with the current behavior, RuntimeInformation.RuntimeIdentifier would return RIDs that were not in the trimmed-down RID graph and so they wouldn't be recognized by the SDK. This seems like incorrect behavior and breaks a bunch of the SDK tests.

The SDK is the driver for this change. And while that may be worth the change, you should treat it as a breaking change, since by lack of any other API that allows to identify a distro, users are probably using it that way too.

[tmds]

The SDK is the driver for this change.

I assume that in most cases the SDK can (should?) use the rid from Microsoft.NETCoreSdk.BundledVersions.props rather than call RuntimeInformation.RuntimeIdentifier.

[ghost]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[tmds]

I assume that in most cases the SDK can (should?) use the rid from Microsoft.NETCoreSdk.BundledVersions.props rather than call RuntimeInformation.RuntimeIdentifier.

@dsplaisted shouldn't the SDK always be using NETCoreSdkRuntimeIdentifier from Microsoft.NETCoreSdk.BundledVersions.props as the host rid?
Doesn't that make this change unnecessary?

[dsplaisted]

I assume that in most cases the SDK can (should?) use the rid from Microsoft.NETCoreSdk.BundledVersions.props rather than call RuntimeInformation.RuntimeIdentifier.

@dsplaisted shouldn't the SDK always be using NETCoreSdkRuntimeIdentifier from Microsoft.NETCoreSdk.BundledVersions.props as the host rid? Doesn't that make this change unnecessary?

I don't think this affects the SDK behavior itself, but it is breaking SDK tests. The tests expect that the value returned by RuntimeInformation.RuntimeIdentifier is a valid RuntimeIdentifier that can be passed to the SDK. I think this is a valid expectation and there may be other code out there with the same expectation.

The SDK and the runtime are changing so that a bunch of RuntimeIdentifiers are no longer valid. This PR makes a part of the runtime more consistent with the changes in the SDK and other parts of the runtime. All of this needs to be documented as potentially breaking changes, but I think that making things consistent with this PR is the right thing.

[vitek-karas]

LGTM - just minor comments

[tmds]

Comments based on the associated change doc pr:

or on Ubuntu 20.04, linux-x64. For non-portable builds (source-build), the build sets a build RID at that can have a version/distro and

fwiw, I think this change is bad because unless you're using RuntimeInformation.RuntimeIdentifier with a rid graph, the resulting code has an unexpected difference (that is: bug) between running on a Microsoft vs a source-built runtime.

Another concern is that this removes the only API that returns a distro identifier:

For the OS version of the actual machine an application is running on, Environment.OSVersion can be used.

This returns the Linux kernel version. It's not the distro version.

For a description, RuntimeInformation.OSDescription can be used.

This is a description, not an identifier.

cc @richlander

[dsplaisted]

fwiw, I think this change is bad because unless you're using RuntimeInformation.RuntimeIdentifier with a rid graph, the resulting code has an unexpected difference (that is: bug) between running on a Microsoft vs a source-built runtime.

I am in favor of this change but some examples of what it could break and the changes that would be necessary can be seen in @elinor-fung's commits in this PR: dotnet/sdk#34349