Stop using computed RID for RUNTIME_IDENTIFIER property - #89598

Merged
elinor-fung merged 4 commits into
dotnet:mainfrom
elinor-fung:noComputedRid
Aug 1, 2023
Merged

Stop using computed RID for RUNTIME_IDENTIFIER property#89598
elinor-fung merged 4 commits into
dotnet:mainfrom
elinor-fung:noComputedRid

Conversation

@elinor-fung

@elinor-fungelinor-fung commented Jul 27, 2023•
edited
Loading

Copy link
Copy Markdown
Member

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

ghost commented Jul 27, 2023

Copy link
Copy Markdown

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

tmds commented Jul 27, 2023•
edited
Loading

Copy link
Copy Markdown
Member

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?

@dsplaisteddsplaisted mentioned this pull request Jul 28, 2023
Merged
@dsplaisted

dsplaisted commented Jul 28, 2023

Copy link
Copy Markdown
Member

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

elinor-fung commented Jul 28, 2023•
edited
Loading

Copy link
Copy Markdown
MemberAuthor

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

agocke commented Jul 28, 2023

Copy link
Copy Markdown
Member

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

tmds commented Jul 28, 2023•
edited
Loading

Copy link
Copy Markdown
Member

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

tmds commented Jul 28, 2023

Copy link
Copy Markdown
Member

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.

@elinor-fungelinor-fung added the breaking-change Issue or PR that represents a breaking API or functional change over a previous release. label Jul 28, 2023
@ghostghost added the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Jul 28, 2023
@ghost

ghost commented Jul 28, 2023•
edited by elinor-fung
Loading

Copy link
Copy Markdown

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

tmds commented Jul 30, 2023

Copy link
Copy Markdown
Member

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

dsplaisted commented Jul 30, 2023

Copy link
Copy Markdown
Member

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
vitek-karas approved these changes Jul 31, 2023
View reviewed changes

@vitek-karasvitek-karas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - just minor comments

Comment threadsrc/native/corehost/fxr/command_line.cpp Outdated
Comment threadsrc/native/corehost/hostmisc/utils.cpp Outdated
Comment threadsrc/native/corehost/hostpolicy/deps_format.cpp Outdated
@elinor-fung
elinor-fung merged commit 865d02e into dotnet:mainAug 1, 2023
@elinor-fung
elinor-fung deleted the noComputedRid branch August 1, 2023 01:45
@elinor-fungelinor-fung mentioned this pull request Aug 1, 2023
Closed
3 tasks
@elinor-fungelinor-fung removed the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Aug 1, 2023
@tmds

tmds commented Aug 2, 2023

Copy link
Copy Markdown
Member

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

dsplaisted commented Aug 2, 2023

Copy link
Copy Markdown
Member

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

@tmdstmds mentioned this pull request Aug 3, 2023
Closed
@ghostghost locked as resolved and limited conversation to collaborators Sep 1, 2023
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@agockeagockeagocke approved these changes
@vitek-karasvitek-karasvitek-karas approved these changes

Assignees

@elinor-fungelinor-fung

Labels

area-Hostbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@elinor-fung@tmds@dsplaisted@agocke@vitek-karas
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Stop using computed RID for RUNTIME_IDENTIFIER property - #89598
Merged
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Aug 1, 2023
Merged
Stop using computed RID for RUNTIME_IDENTIFIER property#89598
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Conversation
@elinor-fung
@elinor-fungelinor-fung
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
ghost
commented
Jul 27, 2023

Copy link


Copy Markdown

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
tmds
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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?
@dsplaisteddsplaisted
mentioned this pull request
Jul 28, 2023
 Merged

@dsplaisted
dsplaisted
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
elinor-fung
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
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
agocke
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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.
@elinor-fungelinor-fung
added
the 
breaking-change
Issue or PR that represents a breaking API or functional change over a previous release.
label
Jul 28, 2023
@ghostghost
added
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Jul 28, 2023
@ghost
ghost
commented
Jul 28, 2023•

edited by elinor-fung

Loading

Copy link


Copy Markdown

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
tmds
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
vitek-karas
approved these changes
Jul 31, 2023
View reviewed changes
@vitek-karasvitek-karas
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - just minor comments
Comment threadsrc/native/corehost/fxr/command_line.cpp
Outdated

Comment threadsrc/native/corehost/hostmisc/utils.cpp
Outdated

Comment threadsrc/native/corehost/hostpolicy/deps_format.cpp
Outdated

@elinor-fung
elinor-fung
merged commit 865d02e
into
dotnet:mainAug 1, 2023
@elinor-fung
elinor-fung
deleted the

noComputedRid

branch
August 1, 2023 01:45
@elinor-fungelinor-fung
mentioned this pull request
Aug 1, 2023

Closed

3 tasks
@elinor-fungelinor-fung
removed
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Aug 1, 2023
@tmds
tmds
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
@tmdstmds
mentioned this pull request
Aug 3, 2023

Closed

@ghostghost
locked as resolved and limited conversation to collaborators
Sep 1, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@agockeagockeagocke approved these changes
@vitek-karasvitek-karasvitek-karas approved these changes

Assignees

@elinor-fungelinor-fung

Labels

area-Hostbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@elinor-fung@tmds@dsplaisted@agocke@vitek-karas

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Stop using computed RID for RUNTIME_IDENTIFIER property - #89598
Merged
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Aug 1, 2023
Merged
Stop using computed RID for RUNTIME_IDENTIFIER property#89598
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Conversation
@elinor-fung
@elinor-fungelinor-fung
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
ghost
commented
Jul 27, 2023

Copy link


Copy Markdown

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
tmds
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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?
@dsplaisteddsplaisted
mentioned this pull request
Jul 28, 2023
 Merged

@dsplaisted
dsplaisted
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
elinor-fung
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
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
agocke
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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.
@elinor-fungelinor-fung
added
the 
breaking-change
Issue or PR that represents a breaking API or functional change over a previous release.
label
Jul 28, 2023
@ghostghost
added
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Jul 28, 2023
@ghost
ghost
commented
Jul 28, 2023•

edited by elinor-fung

Loading

Copy link


Copy Markdown

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
tmds
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
vitek-karas
approved these changes
Jul 31, 2023
View reviewed changes
@vitek-karasvitek-karas
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - just minor comments
Comment threadsrc/native/corehost/fxr/command_line.cpp
Outdated

Comment threadsrc/native/corehost/hostmisc/utils.cpp
Outdated

Comment threadsrc/native/corehost/hostpolicy/deps_format.cpp
Outdated

@elinor-fung
elinor-fung
merged commit 865d02e
into
dotnet:mainAug 1, 2023
@elinor-fung
elinor-fung
deleted the

noComputedRid

branch
August 1, 2023 01:45
@elinor-fungelinor-fung
mentioned this pull request
Aug 1, 2023

Closed

3 tasks
@elinor-fungelinor-fung
removed
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Aug 1, 2023
@tmds
tmds
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
@tmdstmds
mentioned this pull request
Aug 3, 2023

Closed

@ghostghost
locked as resolved and limited conversation to collaborators
Sep 1, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@agockeagockeagocke approved these changes
@vitek-karasvitek-karasvitek-karas approved these changes

Assignees

@elinor-fungelinor-fung

Labels

area-Hostbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@elinor-fung@tmds@dsplaisted@agocke@vitek-karas

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Stop using computed RID for RUNTIME_IDENTIFIER property - #89598
Merged
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Aug 1, 2023
Merged
Stop using computed RID for RUNTIME_IDENTIFIER property#89598
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Conversation
@elinor-fung
@elinor-fungelinor-fung
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
ghost
commented
Jul 27, 2023

Copy link


Copy Markdown

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
tmds
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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?
@dsplaisteddsplaisted
mentioned this pull request
Jul 28, 2023
 Merged

@dsplaisted
dsplaisted
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
elinor-fung
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
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
agocke
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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.
@elinor-fungelinor-fung
added
the 
breaking-change
Issue or PR that represents a breaking API or functional change over a previous release.
label
Jul 28, 2023
@ghostghost
added
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Jul 28, 2023
@ghost
ghost
commented
Jul 28, 2023•

edited by elinor-fung

Loading

Copy link


Copy Markdown

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
tmds
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
vitek-karas
approved these changes
Jul 31, 2023
View reviewed changes
@vitek-karasvitek-karas
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - just minor comments
Comment threadsrc/native/corehost/fxr/command_line.cpp
Outdated

Comment threadsrc/native/corehost/hostmisc/utils.cpp
Outdated

Comment threadsrc/native/corehost/hostpolicy/deps_format.cpp
Outdated

@elinor-fung
elinor-fung
merged commit 865d02e
into
dotnet:mainAug 1, 2023
@elinor-fung
elinor-fung
deleted the

noComputedRid

branch
August 1, 2023 01:45
@elinor-fungelinor-fung
mentioned this pull request
Aug 1, 2023

Closed

3 tasks
@elinor-fungelinor-fung
removed
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Aug 1, 2023
@tmds
tmds
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
@tmdstmds
mentioned this pull request
Aug 3, 2023

Closed

@ghostghost
locked as resolved and limited conversation to collaborators
Sep 1, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@agockeagockeagocke approved these changes
@vitek-karasvitek-karasvitek-karas approved these changes

Assignees

@elinor-fungelinor-fung

Labels

area-Hostbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@elinor-fung@tmds@dsplaisted@agocke@vitek-karas

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Stop using computed RID for RUNTIME_IDENTIFIER property - #89598
Merged
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Aug 1, 2023
Merged
Stop using computed RID for RUNTIME_IDENTIFIER property#89598
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Conversation
@elinor-fung
@elinor-fungelinor-fung
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
ghost
commented
Jul 27, 2023

Copy link


Copy Markdown

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
tmds
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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?
@dsplaisteddsplaisted
mentioned this pull request
Jul 28, 2023
 Merged

@dsplaisted
dsplaisted
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
elinor-fung
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
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
agocke
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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.
@elinor-fungelinor-fung
added
the 
breaking-change
Issue or PR that represents a breaking API or functional change over a previous release.
label
Jul 28, 2023
@ghostghost
added
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Jul 28, 2023
@ghost
ghost
commented
Jul 28, 2023•

edited by elinor-fung

Loading

Copy link


Copy Markdown

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
tmds
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
vitek-karas
approved these changes
Jul 31, 2023
View reviewed changes
@vitek-karasvitek-karas
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - just minor comments
Comment threadsrc/native/corehost/fxr/command_line.cpp
Outdated

Comment threadsrc/native/corehost/hostmisc/utils.cpp
Outdated

Comment threadsrc/native/corehost/hostpolicy/deps_format.cpp
Outdated

@elinor-fung
elinor-fung
merged commit 865d02e
into
dotnet:mainAug 1, 2023
@elinor-fung
elinor-fung
deleted the

noComputedRid

branch
August 1, 2023 01:45
@elinor-fungelinor-fung
mentioned this pull request
Aug 1, 2023

Closed

3 tasks
@elinor-fungelinor-fung
removed
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Aug 1, 2023
@tmds
tmds
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
@tmdstmds
mentioned this pull request
Aug 3, 2023

Closed

@ghostghost
locked as resolved and limited conversation to collaborators
Sep 1, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@agockeagockeagocke approved these changes
@vitek-karasvitek-karasvitek-karas approved these changes

Assignees

@elinor-fungelinor-fung

Labels

area-Hostbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@elinor-fung@tmds@dsplaisted@agocke@vitek-karas

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Stop using computed RID for RUNTIME_IDENTIFIER property - #89598
Merged
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Aug 1, 2023
Merged
Stop using computed RID for RUNTIME_IDENTIFIER property#89598
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Conversation
@elinor-fung
@elinor-fungelinor-fung
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
ghost
commented
Jul 27, 2023

Copy link


Copy Markdown

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
tmds
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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?
@dsplaisteddsplaisted
mentioned this pull request
Jul 28, 2023
 Merged

@dsplaisted
dsplaisted
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
elinor-fung
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
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
agocke
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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.
@elinor-fungelinor-fung
added
the 
breaking-change
Issue or PR that represents a breaking API or functional change over a previous release.
label
Jul 28, 2023
@ghostghost
added
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Jul 28, 2023
@ghost
ghost
commented
Jul 28, 2023•

edited by elinor-fung

Loading

Copy link


Copy Markdown

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
tmds
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
vitek-karas
approved these changes
Jul 31, 2023
View reviewed changes
@vitek-karasvitek-karas
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - just minor comments
Comment threadsrc/native/corehost/fxr/command_line.cpp
Outdated

Comment threadsrc/native/corehost/hostmisc/utils.cpp
Outdated

Comment threadsrc/native/corehost/hostpolicy/deps_format.cpp
Outdated

@elinor-fung
elinor-fung
merged commit 865d02e
into
dotnet:mainAug 1, 2023
@elinor-fung
elinor-fung
deleted the

noComputedRid

branch
August 1, 2023 01:45
@elinor-fungelinor-fung
mentioned this pull request
Aug 1, 2023

Closed

3 tasks
@elinor-fungelinor-fung
removed
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Aug 1, 2023
@tmds
tmds
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
@tmdstmds
mentioned this pull request
Aug 3, 2023

Closed

@ghostghost
locked as resolved and limited conversation to collaborators
Sep 1, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@agockeagockeagocke approved these changes
@vitek-karasvitek-karasvitek-karas approved these changes

Assignees

@elinor-fungelinor-fung

Labels

area-Hostbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@elinor-fung@tmds@dsplaisted@agocke@vitek-karas

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Stop using computed RID for RUNTIME_IDENTIFIER property - #89598
Merged
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Aug 1, 2023
Merged
Stop using computed RID for RUNTIME_IDENTIFIER property#89598
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Conversation
@elinor-fung
@elinor-fungelinor-fung
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
ghost
commented
Jul 27, 2023

Copy link


Copy Markdown

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
tmds
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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?
@dsplaisteddsplaisted
mentioned this pull request
Jul 28, 2023
 Merged

@dsplaisted
dsplaisted
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
elinor-fung
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
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
agocke
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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.
@elinor-fungelinor-fung
added
the 
breaking-change
Issue or PR that represents a breaking API or functional change over a previous release.
label
Jul 28, 2023
@ghostghost
added
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Jul 28, 2023
@ghost
ghost
commented
Jul 28, 2023•

edited by elinor-fung

Loading

Copy link


Copy Markdown

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
tmds
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
vitek-karas
approved these changes
Jul 31, 2023
View reviewed changes
@vitek-karasvitek-karas
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - just minor comments
Comment threadsrc/native/corehost/fxr/command_line.cpp
Outdated

Comment threadsrc/native/corehost/hostmisc/utils.cpp
Outdated

Comment threadsrc/native/corehost/hostpolicy/deps_format.cpp
Outdated

@elinor-fung
elinor-fung
merged commit 865d02e
into
dotnet:mainAug 1, 2023
@elinor-fung
elinor-fung
deleted the

noComputedRid

branch
August 1, 2023 01:45
@elinor-fungelinor-fung
mentioned this pull request
Aug 1, 2023

Closed

3 tasks
@elinor-fungelinor-fung
removed
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Aug 1, 2023
@tmds
tmds
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
@tmdstmds
mentioned this pull request
Aug 3, 2023

Closed

@ghostghost
locked as resolved and limited conversation to collaborators
Sep 1, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@agockeagockeagocke approved these changes
@vitek-karasvitek-karasvitek-karas approved these changes

Assignees

@elinor-fungelinor-fung

Labels

area-Hostbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@elinor-fung@tmds@dsplaisted@agocke@vitek-karas

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Stop using computed RID for RUNTIME_IDENTIFIER property - #89598
Merged
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Aug 1, 2023
Merged
Stop using computed RID for RUNTIME_IDENTIFIER property#89598
elinor-fung merged 4 commits into
dotnet:mainfrom 
elinor-fung:noComputedRid
Conversation
@elinor-fung
@elinor-fungelinor-fung
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
ghost
commented
Jul 27, 2023

Copy link


Copy Markdown

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
tmds
commented
Jul 27, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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?
@dsplaisteddsplaisted
mentioned this pull request
Jul 28, 2023
 Merged

@dsplaisted
dsplaisted
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
elinor-fung
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
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
agocke
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023•

edited

Loading

Copy link


Copy Markdown

Member
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
tmds
commented
Jul 28, 2023

Copy link


Copy Markdown

Member
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.
@elinor-fungelinor-fung
added
the 
breaking-change
Issue or PR that represents a breaking API or functional change over a previous release.
label
Jul 28, 2023
@ghostghost
added
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Jul 28, 2023
@ghost
ghost
commented
Jul 28, 2023•

edited by elinor-fung

Loading

Copy link


Copy Markdown

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
tmds
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Jul 30, 2023

Copy link


Copy Markdown

Member
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
vitek-karas
approved these changes
Jul 31, 2023
View reviewed changes
@vitek-karasvitek-karas
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - just minor comments
Comment threadsrc/native/corehost/fxr/command_line.cpp
Outdated

Comment threadsrc/native/corehost/hostmisc/utils.cpp
Outdated

Comment threadsrc/native/corehost/hostpolicy/deps_format.cpp
Outdated

@elinor-fung
elinor-fung
merged commit 865d02e
into
dotnet:mainAug 1, 2023
@elinor-fung
elinor-fung
deleted the

noComputedRid

branch
August 1, 2023 01:45
@elinor-fungelinor-fung
mentioned this pull request
Aug 1, 2023

Closed

3 tasks
@elinor-fungelinor-fung
removed
the 
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Aug 1, 2023
@tmds
tmds
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
dsplaisted
commented
Aug 2, 2023

Copy link


Copy Markdown

Member
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
@tmdstmds
mentioned this pull request
Aug 3, 2023

Closed

@ghostghost
locked as resolved and limited conversation to collaborators
Sep 1, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@agockeagockeagocke approved these changes
@vitek-karasvitek-karasvitek-karas approved these changes

Assignees

@elinor-fungelinor-fung

Labels

area-Hostbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@elinor-fung@tmds@dsplaisted@agocke@vitek-karas