CODEWITHSUNDEEP
wixwindows-installerinstallshield
jbudreau
jbudreau

Reputation: 1307

VersionNT MSI property on Windows 10

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?

Upvotes: 9

Views: 16860

Answers (5)

tiberriver256
tiberriver256

Reputation: 539

Microsoft official answer:

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

Source

Upvotes: 5

technoHermit
technoHermit

Reputation: 21

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

Upvotes: 2

Christopher Painter
Christopher Painter

Reputation: 55601

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...)

Upvotes: 20

shpuktzy
shpuktzy

Reputation: 33

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.

Upvotes: 0

Michael Urman
Michael Urman

Reputation: 15905

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.)

Upvotes: 3

Related Questions