Feature Usage - Windows 10 detection

AndreL

Hi,

SmartAssembly reports Windows 10 as Windows 8 under feature usage on my system. Why is this happening and how can this be addressed?

Thanks

Tomasz

I how exaclty the same problem, I use SmartAssembly 6.9.

Russell D

Hi, there's a bug in the operating system detection code, we're looking into this.

Russell D

Ok so I've gotten to the bottom of this, it's not as easy to solve as you might think however.

After some digging, I found that no matter what, the OS version I was getting is 6.2.9200.0, which is Windows 8 (I'm using Windows 10):


So after further digging, I came across this: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724832(v=vs.85).aspx, specifically:

Applications not manifested for Windows 8.1 or Windows 10 will return the Windows 8 OS version value (6.2). To manifest your applications for Windows 8.1 or Windows 10, refer to Targeting your application for Windows.

This leads on to https://msdn.microsoft.com/en-us/library/windows/desktop/dn481241(v=vs.85).aspx. So I created an app.manifest for my test program, and hey presto:




So there's really two questions that need addressing here. The first is how we address OS detection in the .net framework, because the method we're using seems flawed. OSVersion has been deprecated, so it's questionable that we should be using this at all, but as above, with the appropriate files in place it works as intended.

However, the second thing that needs addressing is that the recommended best practice is to properly manifest your programs, and so perhaps we shouldn't be supporting those that don't use a manifest. That will require some more thought though.

I'm just repairing a pull request to fix the OS detection code based on using a manifest file, once released I'll update this post, and then I suggest you create an application manifest that includes the Windows 10 guid.

Russell D

SmartAssembly 6.11.1.406 has been released to Check for Updates, and will now correctly report Windows 10 if an application manifest is used.

mltgames

Humm where is the UBR version for windows 10? its good to have the build # but the UBR (Update Build Revision) is a nice to have.

Russell D

Actually thinking about this, what's wrong with the version pulled from Winver thats currently displayed? Eg 10.0.14393.0. You'd rather be given the version number eg 1607 in this case? Just trying to determine what that gives you over the build number when its easily verified.

mltgames

Thanks for the quick reply,

It's just a suggestion / a nice to have.

Currently, it displaying 10.0.15063.0 for me instead of 10.0.15063.296. 296 is my UBR.


Like the latest version on wikipedia https://en.wikipedia.org/wiki/Windows_10 it is 10.0.15063.296, with the 296 you know which monthly updates are installed on the machine.

Russell D

Thanks for clarifying that - I've added the enhancement request.

AndreL

Russell, thank you for the fix.

Russell D

mltgames wrote: »

Thanks for the quick reply,

It's just a suggestion / a nice to have.

Currently, it displaying 10.0.15063.0 for me instead of 10.0.15063.296. 296 is my UBR.


Like the latest version on wikipedia https://en.wikipedia.org/wiki/Windows_10 it is 10.0.15063.296, with the 296 you know which monthly updates are installed on the machine.

Looking at this a little further, I'm not entirely sure its possible to get this UBR with how we're detecting the version information. UBR doesn't appear to be supported - every test I've run just pulls out .0. I'll speak to a colleague about it and see if we can do anything but if it needs a rewrite of the OS detection class I'm not sure we'll pursue it due to the knock on effects this could have.

@AndreL you're welcome.