Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change Environment.OSVersion to return actual OS version on Windows #33643

Closed
jkotas opened this issue Mar 16, 2020 · 5 comments · Fixed by #33651 or #36302
Closed

Change Environment.OSVersion to return actual OS version on Windows #33643

jkotas opened this issue Mar 16, 2020 · 5 comments · Fixed by #33651 or #36302
Assignees
Labels
area-System.Runtime breaking-change Issue or PR that represents a breaking API or functional change over a prerelease.
Milestone

Comments

@jkotas
Copy link
Member

jkotas commented Mar 16, 2020

Environment.OSVersion returns quirked OS version from app manifest on Windows. Consider changing it to return the actual OS version. It's not the recommended solution, but so many times I've seen folks say that Environment.OSVersion is buggy and then go and just do the P/Invoke themselves (or parse some other string-based representation that's doing it).

Related:

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-System.Runtime untriaged New issue has not been triaged by the area owner labels Mar 16, 2020
@GrabYourPitchforks
Copy link
Member

How do we intend on getting this information? The HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion reg keys?

This needs to be coordinated with the Windows team. I don't know about the other keys, but they've said in crystal clear terms that BuildLab and BuildLabEx keys are intended to be human-readable strings used for debugging, and applications should under no circumstance attempt to parse these strings as they're not guaranteed stable across versions.

@jkotas
Copy link
Member Author

jkotas commented Mar 16, 2020

RtlGetVersion. We are using this API in System.Runtime.InteropServices.RuntimeInformation already.

@dougbu
Copy link
Member

dougbu commented Mar 17, 2020

With the property be quirked to avoid breaking applications expecting the old behaviour? Probably something of a corner case but…?

@stephentoub
Copy link
Member

Will the property be quirked to avoid breaking applications expecting the old behaviour? Probably something of a corner case but…?

Wasn't planning on it.

@davidsh
Copy link
Contributor

davidsh commented Mar 17, 2020

Wasn't planning on it.

It should, though, be documented as a 'breaking-change' for .NET 5.

@davidsh davidsh added the breaking-change Issue or PR that represents a breaking API or functional change over a prerelease. label Mar 17, 2020
ghost pushed a commit to dotnet/sdk that referenced this issue May 14, 2020
Now that dotnet/runtime#34977 and dotnet/runtime#33643 are fixed, Environment.OSVersion returns the correct version for Windows and macOS.
@ghost ghost locked as resolved and limited conversation to collaborators Dec 10, 2020
@tannergooding tannergooding removed the untriaged New issue has not been triaged by the area owner label Jun 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Runtime breaking-change Issue or PR that represents a breaking API or functional change over a prerelease.
Projects
None yet
7 participants