Application does not respect the system color settings due to bad detection by SystemColorsSupported

[SuperMartas]

If I try to use the library in my .NET Core 3.1 project, the system color settings is not respected when running from Visual Studio or directly from exe. This is not a problem in JetBrains Rider IDE. The issue is that Environment.OSVersion.Version (used in ColorsHelper.SystemColorsSupported) shows version 6.2.9200 but the library tests Major version for >=10, which can't happen. This could happen because of this: https://docs.microsoft.com/en-US/windows/win32/sysinfo/targeting-your-application-at-windows-8-1 (https://www.prugg.at/2019/09/09/properly-detect-windows-version-in-c-net-even-windows-10/).

I found out a temporary workaround by adding app.manifest to the project (right click on project in solution explorer -> Add -> New item... -> Application Manifest File (Windows only)) and then uncommenting line <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />.

[HadriMX]

I don't think that's a workaround, I think that's the right way to do it.

[ShankarBUS]

If the info about the need of app.manifest and how to add it properly is added to README, it will reduce confusion and will be helpful to new users.

[SuperMartas]

Wouldn't it be better to detect if the system colors are supported in another way if possible (rather than detecting it by OS version)? I don't think this is a good practice and Microsoft developers do not think it either:
"Avoid writing code that depends on a reported operating system version. Instead, check for the availability of the features that your application needs."
https://docs.microsoft.com/en-us/dotnet/api/system.environment.osversion?view=netcore-3.1

[ShankarBUS]

Hey @SuperMartas,

That's because this library uses WinRT (UWP) APIs to fetch system themes and colours on Windows 10 and will fallback on older windows versions. Thus the version check is added to prevent exceptions, it could be reason to add the manifest.

You're right. Instead of checking the version, the API availability could be checked.

[sabihoshi]

It actually used to, on .NET 5 preview 5. I'm unsure what has changed, but adding the manifest file and changes fixed it for me as well.

[ShankarBUS]

@hizamakura, What?

[sabihoshi]

Sorry, I mean it fetched the system's default color properly on .NET 5 Preview 5. After updating the preview version to Preview 6, the app wouldn't run at all, and I had to switch to .NET Core 3.1 and I observed the same issues. I get System.Windows.Markup.XamlParseException: ''Initialization of 'ModernWpf.ThemeResources' threw an exception.' Line number '17' and line position '18'.' PlatformNotSupportedException: Operation is not supported on this platform. (0x80131539) errors on the latest preview as of now.

[ShankarBUS]

Yes, they removed inbuilt WinRT support starting from preview 6. It won't work the same way now like it used to in .NET Core 3.x or .NET 5 preview 5. It's a different issue (see #140).

But this issue can happen on .NET Framework, .NET Core 3.x and .NET 5. Adding app.manifest and un-commenting the supported OSes will solve this issue. While the .NET 5 issue is a separate one (see #140)

[Kinnara]

I'm not aware of a reliable way to check the availability of WinRT, but implementing OS version check without requiring app.manifest should be doable.

[Kinnara]

The requirement of app.manifest has been removed by 2c27fba.