NUnitLite incorrectly reports Win 10 OS name

[ChrisMaddock]

NUnitLite incorrectly reports Environment.OSVersion as Windows 8, when running on Windows 10. The property has been deprecated. This is shown in the main console output, xml, and a couple of other places.

The simple workaround is to add an app.manifest, as the console runner has. (The Console runner reports correctly.)

Alternatively, looks like the existing OSPlatform class might already work around this situation.

[CharliePoole]

In the console output, do you mean under RunTime Environment? Unless you are going to take this and do a PR, it would help to be more specific for all the places.

I'm not sure we can add an app manifest, since the user writes the main exe when running NUnitLite. If it looks like OSPlatform would help, that might be best.

[ChrisMaddock]

You're right about the app.manifest...I didn't really think that through, did I...

Regarding where it's used, I just did a grep for Environment.OSVersion 😄 But the place I noticed it first was under 'Runtime Environment' in the main console output (TextUi.cs) - although it also seems to be used in various other places.

Looks like these should possibly use OSPlatform then.

[rprouse]

I wonder if the behavior isn't correct since it is reporting that you are running in Win 8 compatibility mode because you don't have a proper manifest?

[ChrisMaddock]

That may well be the reason behind it, yes. 😄 I don't have much of an idea how these things work.

The note from MSDN is:

Starting with Windows 8, the OSVersion property returns the same major and minor version numbers for all Windows platforms. Therefore, we do not recommend that you retrieve the value of this property to determine the operating system version.

This property doesn't seem like the best way to be getting this info anymore.

[kintar]

@ChrisMaddock : Can you give steps to reproduce this? Everything that I'm seeing looks like it reports the correct OS version on Windows 10.

[ChrisMaddock]

@kintar - Are you definitely looking at the NUnitLite runner, as opposed to the nunit3-console?

I suggest you download the .zip release from here. https://github.com/nunit/nunit/releases. Then navigate to /bin/net-4.5 and run nunitlite.tests.exe. You should see this - which highlights the problem. 🙂

Are you interested in submitting a PR for this? 😄 In terms of a fix - sounds we should replace Environment.OSVersion with OSPlatform, but that solution may not work on all platforms - you'd have to check it out. I'd also suggest searching the codebase, to see if the same Environment.OSVersion is also used in other places, which may need replacing.

[kintar]

@ChrisMaddock

Oh, I was definitely NOT looking in the right place. I see it now. :)

Looks like the only other place using Environment.OSVersion is the FrameworkController, but it's injecting the OSVersion.ToString() result into the os-version environment attribute. If we move to OSPlatform that will nuke the text description from that attr. I.e., "Microsoft Windows NT 6.2.9200.0" would just become "6.2.9200.0" (or "10.0.<whatever>"). The only way around that would be to implement a ToString() on OSPlatform, and a quick Google didn't reveal any insights as to what the non-Win32NT versions of that string should be.

So the question becomes : Is the text platform name necessary? Will it break half the projects using NUnit if we change the way the os-version environment attribute gets populated?

[kintar]

I left FrameworkController alone. I figure someone can open a separate issue if the difference between the TextUI output and the os-version environment value is a problem. :)

[rprouse]

Closed by #2468