-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Provide APIs to determine OS, Distribution, Version, Bitness and other useful Info #18993
Comments
On Environment we now have OSVersion, Is64Bit, Is64BitProcess |
Which version of the product is that for? 1.2? |
Yes |
.NET Core 1.0 actually has more of this information, via |
For 1.0, the APIs that @mellinoe pointed you to should address these concerns partially. Most of the APIs return strings, but depending on your use case this might work. |
Ok, so is this already addressed then in 1.2 with .NET Standard 2.0 support? |
@Petermarcu @richlander mentioned
So nothing about "16.04 LTS", or "xenial". |
So @richlander, are you looking to have Description and Codename exposed? |
@richlander are you wanting this information just as a description string or in some other form? Do you expect people to make runtime decisions based on it? If we want more APIs we need to put someone on this and write a design proposal for the scenarios we want to support. I also agree with @mellinoe that we should be preferring RuntimeInformation for new APIs over putting them on Environment because the Environment class doesn't have the agility we need in order to support the ever changing number of runtimes/os/etc we want to run on. |
/cc @leecow |
Since you mention lsb_release for retrieving this information, not all Linux distributions are LSB compliant. I had considered using this function while implementing I may be wrong, but I couldn't find a reliable way to get distro version and other distro specific info through a single API that is universal across Linux. When such standard is not provided by the OS, I am not sure how a reliable solution can be provided through .NET. |
Regardless of how we implement this, @richlander do we want to have the API? If we do, then we are going to need a formal API proposal for them. |
Looks like @leecow has a proposal for this, which is great, with dotnet/corefx#16629. |
I would like to be able to get this information from System.Environment.
I've been recently playing with the lsb_release command. I should be able to get most of this same information from System.Environment.
I saw some earlier discussions on some APIs leading to bad practices (for example, checking feature availability based on versions). All true, but I don't think we should use those bad practices as a reason not to make APIs available. That's the role of documentation and samples, IMO.
Related: https://github.com/dotnet/corefx/issues/1017
The text was updated successfully, but these errors were encountered: