Environment.OSVersion has misleading notes on 8/10 compatibility about dotnet-api-docs HOT 7 OPEN

Thanks for the detailed feedback @ocdtrekkie we do appreciate it.

The docs definitely should be updated, the rule recommendation on the analyzer mentioned above is based that we see more cases of misuse then good use of the API. So let's update the docs but keep the current recommendation on the analyzer (it links to the doc for more info anyway).

from dotnet-api-docs.

For sure, we need to improve those docs @ocdtrekkie since the information there is not correct and not complete. I was just trying to confirm if there was anything else I was missing.

@rpetrusha @merriemcgaw should we also update the high DPI article to show how to check for versions using RuntimeInformation.IsOSPlatform(OSPlatform) on newer apps?

This issue also made me realize we don't have good docs on the application manifest file. I'll create new issues if we deem that these other tasks should be done and keep this one focused on the API docs.

from dotnet-api-docs.

Thanks for your feedback @ocdtrekkie. We'll investigate. @karelz who owns System.Environment that could help here too?

from dotnet-api-docs.

I just tested this on .NET Core and .NET Framework. It seems that .NET Framework does return the correct value when the application manifest targets the OS, but Core doesn't seem to do that. If the application is not manifested to the target OS, then the comments on the current page applies.

We should probably add the information from here too: https://github.com/dotnet/platform-compat/blob/master/docs/DE0009.md

/cc @pjanotti @terrajobst any comments?

from dotnet-api-docs.

The type is in System.Runtime.Extensions - @joperezr (per area owners page)

from dotnet-api-docs.

In the context of CoreFX it seems reasonable to continue with current recommendation of DE0009. dotnet/platform-compat#58 has the reasoning for that.

from dotnet-api-docs.

As noted in my case, I check the version to see if my computer is up to date, since the computer is rarely online and cannot necessarily check for itself. (Right now, I know my home PC is on 15063.909, but my car PC, through my .NET app, says it's on 15063.786, ergo, I know it's out of date!)

I totally understand the desire for people not to use it for compatibility checks (given I have software at work I have to convince is running on a Vista machine to get it to install on Windows 10), though people who want to do that can do what I ended up doing here: a WMI call to grab all of the version info I wanted from the registry. (I find some personal irony in that, of course, it's recommended not to check the OSVersion for compatibility, but the High DPI in Windows Forms article, written a mere year ago, recommends doing just that.)

Anyways, this issue file was more meant to be a docs issue more than an opinion on .NET's functionality itself: The note and remarks here on Docs are from when Windows 8 and 8.1 were current, don't mention the supportedOs option explained in the High DPI article, and if this is different between .NET Core and .NET Framework, the remarks on this page should probably be updated to communicate that as well.

from dotnet-api-docs.