We have BASIC MSI attempting to create an install package for Windows 10 and beyond. I have read the KB article 'Identifying Windows 10 with MSI ' and the workaround if we don't have the Suite version. The workaround is not preferred since the workaround accesses the CurrentVersion in the registry which is not guaranteed not to change according to the article. It is hard to believe there is not another solution so I am trying to find another way.
Have not worked with installShield or MSI for 10 or so years so I am very rusty. I am trying to execute some custom code(powershell) that can set a user defined value ,after querying windows for its version, that can be checked when the Install Condition step is executed. I cannot figure out if this is possible to do before the Install Condition step.
Is this possible and if not, do I have any alternative to the stated workaround?
You are welcome; we are happy to help. Thank you for your reply.
Based on visual inspection of the PowerShell script, nothing jumps out at me as being incorrect as far as I know, at least offhand, except for possibly needing to specify a -ClassName parameter before Win32_OperatingSystem. But maybe I'm missing something.
A potential catch that I see involves the environment variable that it looks like you're setting. There's a chance that the Windows environment variables will not be refreshed in time, so that the environment variable that you set is accessible to the installer itself.
In summary, I'm not aware of any issues with this approach offhand. However, we suggest testing this implementation as thoroughly as possible, which you were probably going to do anyway.
Please let us know whether this implementation works for you, so that we can note it for future reference as a possible workaround to this Windows Installer limitation. That would be very helpful to know.
Please let us know if you have any questions or concerns. Thanks!
No, there are no alternatives, because per Microsoft's design of Windows Installer, the VersionNT MSI property cannot be used to differentiate among Windows 8.1, Windows 10, and Windows 11, since the value remained the same. Since only Microsoft authored Windows Installer (MSI), you would need to contact Microsoft directly to request a change in Windows Installer behavior, which is what Basic MSI projects are based on.
Please let us know if you have any questions or concerns. Thanks!
I did implement a method that could possibly handle the version issue above. I am concerned that there is something I am missing that may invalidate this method. What I did was to use a powershell script custom action that places the Windows version in the user environment of the registry. It is designated as First Action in the install UI process and the Install Condition checks that value later in the install process. It seems to work but can you tell me if this will cause any problems that I have overlooked? The powershell script does the following
You are welcome; we are happy to help. Thank you for your reply.
Based on visual inspection of the PowerShell script, nothing jumps out at me as being incorrect as far as I know, at least offhand, except for possibly needing to specify a -ClassName parameter before Win32_OperatingSystem. But maybe I'm missing something.
A potential catch that I see involves the environment variable that it looks like you're setting. There's a chance that the Windows environment variables will not be refreshed in time, so that the environment variable that you set is accessible to the installer itself.
In summary, I'm not aware of any issues with this approach offhand. However, we suggest testing this implementation as thoroughly as possible, which you were probably going to do anyway.
Please let us know whether this implementation works for you, so that we can note it for future reference as a possible workaround to this Windows Installer limitation. That would be very helpful to know.
Please let us know if you have any questions or concerns. Thanks!
