VersionNT MSI property on Windows 10 - wix

Question

I'm finding that when I update the manifest for my bootstrapper to support Windows 10 compatability, the InstallUISequence of the MSI will correctly set VersionNT=1000, but the InstallExecuteSequence will set VersionNT=603.
How do I make the InstallExecuteSequence also set VersionNT=1000?

Answer 1

Here's my two cents....
I don't find the VersionNT property terribly useful. VersionNT64 is: VersionNT64 .... Not VersionNT64 to determine bitness.
This is a bit of a hack (they do this, we do that...) but desperate times call for desperate measures....
In all of the compatibility games MSFT is playing they only seem to be masking the Major and Minor but Build and revision. I've also worked out that on Win8 they mask it as 6.2 and on Win 10 they mask it as 6.3. So therefore I feel comfortable doing this:
<Property Id="WIN10FOUND">
<DirectorySearch Id="searchSystem" Path="[SystemFolder]" Depth="0">
<FileSearch Id="searchFile" Name="advapi32.dll" MinVersion="6.3.10000.0"/>
</DirectorySearch>
</Property>
What I tend to do ask myself is "WHY" do I need Windows (FOO)? I then look for some registry entry or DLL that indicates that particular feature, component, API is present and use that for my test.
Microsoft has adopted an evergreen approach of "you don't need to know what version it is, you'll always have the latest and it'll always be called Windows 10" and to me this reinforces the approach I prefer to take. I know that a day will come that they are wrong and I do need to know otherwise I'll install and my application will fail and my users will complain and not know what version they have. (Sigh...)

Answer 2

Microsoft official answer:
When you install an .msi installation package on Windows 10 or Windows Server 2016, the VersionNT value is 603.
Source

Answer 3

Since msiexec.exe does not have Windows 10 compatibility in its manifest, and VersionNT is a private property, there is no clean way I'm aware of to make the execute sequence see VersionNT=1000. I would recommend one of these approaches:
copy VersionNT to another property during the UI sequence (some public property like REALVERSIONNT; be sure to list it in SecureCustomProperties like any other property you want to pass to the execute sequence),
pass in the real value from your bootstrapper (ditto), or
possibly set a registry key in your bootstrapper if you need the same information during maintenance or uninstallation, then pull its value into the installation with a system search.
(I'm torn about the registry key option, as it can go stale if the OS is upgraded in the future. Note as well that all of these options are likely to be only as correct as the manifest on your bootstrap in a theoretical future version of Windows.)

Answer 4

I found that a very easy and robust way of detecting Windows 10 is by calling the built-in WMIC command and parsing the output from it:
wmic os get Name,Version,BuildNumber /VALUE
it'll return exactly the info you need to determine which OS you're on:
BuildNumber=14393
Version=10.0.14393
http://helpnet.flexerasoftware.com/installshield22helplib/helplibrary/whats_newIS2015.htm
On systems with Windows 10, the Windows Installer properties VersionNT
and VersionNT64 indicate 603, which was originally introduced as the
version number of Windows 8.1. Therefore, it is not possible to create
conditions in an .msi package that specifically target Windows 10.
Since Windows Installer 5.0 and Windows 7, DLL custom actions in .msi
packages are shimmed to block obtaining the operating system version;
the APIs GetVersion, GetVersionEx, and RtlGetVersion return a Windows
version of 6.0.6000, which was originally the version number of
Windows Vista. Therefore, it is also not possible to obtain the actual
version number of Windows from a DLL custom action or from an
InstallScript custom action (which is implemented as a DLL).
Because of the aforementioned behavior in Windows Installer, it is not
easily possible to detect what version of Windows on which an .msi
package is running

Answer 5

For installers that do not have a bootstrapper, I've found that creating an immediate custom action that calls GetVersionEx() and sets a property for the rest of the installer to use is also a good alternative.
I've sequenced my custom action to occur after AppSearch, and it was enough to condition components with it.