INSTALLED应该为Installed. 属性区分大小写，因此您必须根据情况加以解决-否则，条件永远不会成立-即使已安装产品.

INSTALLED should be Installed. Properties are case sensitive and you must definitely fix that in your condition - or else that part of the condition will never be true - even if the product is installed.

其余条件实际上看起来还可以.只是一些想法来确定出什么问题了:

The rest of the condition looks OK actually. Just some ideas to determine what is wrong:

1. WiX源元素 :您确定已将此条件包含在WiX源的正确位置吗?

1. WiX Source Element: Are you sure you have included this condition in the right location in the WiX source?

• 我将其直接放在Product元素下.证明在已编译的MSI文件中.查看 LaunchCondition表 .
• 我假设您可以与Orca进行检查，否则请使用其他免费MSI查看器之一(朝下): 无版本 :在Windows 10中检测OS版本的方式已发生了巨大变化.我不知道这是否也会影响Windows Server 2012R2.

  Versionlessness: There have been massive changes to how the OS version is detected in Windows 10. I don't know if this also affects Windows Server 2012R2 as well.

  • 似乎总的想法是Windows现在是常绿的无版本"(术语是什么意思)-意味着VersionNT不一定完全报告正确的操作系统版本！
  • 请阅读此答案，而不要在这里重复我的内容: Windows 10无法在installshield上检测到 .
  • It seems the overall idea is that Windows is now "evergreen versionless" (how is that for a term) - meaning that VersionNT does not necessarily report the correct version of the OS at all!
  • Please read this answer rather than me repeating things here: Windows 10 not detecting on installshield.

  为了确定VersionNT的值实际在您的设置中是什么，我将使用两种方法之一在运行时检查属性.后一个选项(日志记录)通常更快，更容易，而第一个选项使您还可以在安装程序运行时评估复杂的条件，并通过使用

  In order to determine what the value of VersionNT really is in your setup, I'd use one of two ways to check properties at runtime. The latter option (logging) is generally quicker and easier, whereas the first option allows you to also evaluate complex conditions as the setup runs and show whether they are true or false at runtime by using the Session.EvaluateCondition method (I use this method call when conditions are complex and confusing and I want some runtime proof that they behave like I expect):

  1. 属性调试器VBScript :我有一个属性调试器VBScript，用于在运行时显示MSI文件的一系列属性值并评估以下条件:运行时，以显示它们的评估结果是否为真-如上所述.如果我是您，我将使用这样的脚本在运行时显示VersionNT(以及您要检查的任何其他属性或条件).

  1. Property Debugger VBScript: I have a property debugger VBScript I use to display a bunch of property values at runtime for an MSI file and to evaluate conditions at runtime to show whether they evaluate to true or not - as stated above. If I were you I would use such a script to display VersionNT at runtime (and whatever other property or condition you want to check).

  • 建议您不要将VBScript用于生产设置-仅调试 . Rob 是 WiX创造者-我同意他的所有反脚本论点，但个人仍然认为VBScript对于调试非常有用-快速，简便，实用.无需编译的嵌入式源代码.设置整个已编译的自定义操作以仅检索一些属性进行测试是非常耗时的(尽管使用真实代码"(例如C ++)进行调试会更好，但也会更容易).
  • 在企业环境中，由于嵌入式源，VBScript得到了广泛的使用-您始终可以找到嵌入在MSI中的真正的自定义操作源-在已编译的自定义操作中，您经常可以找到已嵌入的自定义操作源(由于现实世界中所有技术问题的固有混乱)，这可能是不可用的.
  • 另一个好处是VBScript的简单性以及公司应用程序打包程序如何比C ++/C#更好地掌握了复杂性.但是总体脚本自定义操作总是会引起Rob提到的问题(防病毒阻止，较差的调试和没有适当错误处理的乏味编码).
  • 至关重要的是，您将可以在公司部署方案中控制安全软件/防病毒软件.您可以以逻辑方式处理问题并进行调整，直到程序包可靠部署为止.
  • 最终，企业台式机是SOE-标准化平台，与常规PC相比，可变性要小得多((状态的多样性可能更大，因此会出现更多的部署问题).)
  • 真正的问题基本上是自定义操作，它们很容易出错:
  • It is recommended that you don't use VBScript for production setups - debugging only. Rob is the WiX creator - I agree with all his anti-script arguments, but personally still conclude that VBScript is useful for debugging - quick, easy & embedded source with no compilation. Setting up a whole compiled custom action just to retrieve a few properties for testing is overly time consuming (debugging would be better though and easier with "real code" such as C++).
  • In corporate environments VBScript has seen lots of use because of the embedded source - you can always find the real custom action source embedded in the MSI - not so with compiled custom actions where the source you compiled from could be unavailable (due to the inherent chaos of all things technical - in the real world) - which is very bad indeed.
  • Another benefit is the simplicity of VBScripts and how corporate application packagers master the complexity better than C++ / C#. But overall script custom actions always cause problems along the lines of what Rob mentions (anti-virus blocking, poor debugging and lackluster coding without proper error handling).
  • Crucially you will have control of security software / anti virus in corporate deployment scenarios. You can deal with problems in a logical way and tweak things until the package deploys reliably.
  • Finally corporate desktops are SOEs - standardized platforms with much less variability than regular PCs (which can be in a much greater diversity of states and hence see more deployment problems).
  • The real problem is basically custom actions altogether, they are very error prone: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups? A lot more information than you need I guess. The moral of the story for me is: use whatever gets the job done quickest, but don't think scripts are good enough for production code for world-wide distribution.
  • For corporate deployment one should eliminate ad-hoc script custom actions in favor of well-tested C++ custom actions with full rollback support driven by custom MSI tables which yields full declaration of what should happen during the install.

  记录 :只需为安装程序创建一个日志文件，然后检查其中的VersionNT值.我喜欢为所有设置启用日志记录，如下所述: 安装站点.org上的日志记录方法 -请参见"计算机上所有设置的全局设置"部分).尽管性能受到影响，但我始终在TEMP folder中准备好一个日志文件以进行调试.相同的链接将向您展示如何仅针对单个安装制作临时日志(本质上:msiexec.exe /i "c:\filename.msi" /QN /L*V "C:\msilog.log" REBOOT=R-具有日志记录的静默安装并禁止重新启动-

  Logging: Just create a log file for the setup and check the value of VersionNT in it. I like to enable logging for all setups as explained here: installsite.org on how to do logging - see the "Globally for all setups on a machine"-section). Despite the performance hit, I always have a log file ready in the TEMP folder for debugging. The same link will show you how to make an ad-hoc log for a single install only as well (essentially: msiexec.exe /i "c:\filename.msi" /QN /L*V "C:\msilog.log" REBOOT=R - silent install with logging and suppressed reboot - even more logging info).

  ---

  属性调试器演示 :这超出了您的要求，但是我认为您可能难以调试此问题以及用于服务器部署的类似问题，我想为您提供有关如何在VBScript中评估MSI条件的快速演示.

  ---

  Property Debugger Demo: This is beyond what you asked, but I think you may struggle to debug this issue and similar ones for your server deployments, and I want to give you a quick demo on how to evaluate MSI conditions in VBScript.

  您的上述条件通常太简单了，以至于无法解决此问题，但这是处理非常复杂条件的通用方法-例如，当您只想在维修或主要升级启动的卸载程序上运行自定义操作时-证明总是在测试中，无论您如何努力思考.

  Your condition above is generally too simple to bother with this, but this is a general approach for very complicated conditions - for example when you want to run a custom action only on repair or on major upgrade initiated uninstalls - the proof is always in testing, no matter how hard you think about things.

  使用VBScript在运行时评估您的条件:

  Your condition evaluated at runtime using VBScript:

  MsgBox "Condition: " & CBool( Session.EvaluateCondition("Installed OR (VersionNT >= 603)"))
  

  可以根据需要在不同的序列和不同的位置插入这样的VBScript自定义操作.属性值可能会有所不同，具体取决于您的排序(！)以及您所处的安装模式(install，uninstall，repair，modify， self-repair，major upgrade(涉及一个正在安装的MSI和一个正在卸载的MSI)，minor upgrade，minor upgrade patch，major upgrade patch等...)以及是否在deferred或immediate中运行 >上下文，或者您是静默还是交互式运行，以及我忘记的任何变量-MSI中有很多活动部件.例如，如果您在UI序列的开头插入自定义操作，则AppSearch尚未运行，并且某些属性尚未设置.如果需要，还可以在administrative-和advertisement-installation序列中插入属性调试构造.

  Such a VBScript custom action can be inserted in different sequences and in different locations as you wish. Property values may differ depending on your sequencing (!) and also what installation mode you are in (install, uninstall, repair, modify, self-repair, major upgrade (involves one MSI being installed and one being uninstalled), minor upgrade, minor upgrade patch, major upgrade patchetc...) and whether you are running in deferred or immediate context or whether you are running silently or interactively, and whatever variable I have forgotten - lots of moving parts in MSI. For example if you insert the custom action at the beginning of the UI sequence, then AppSearch has not run yet, and some properties are not yet set. You can also insert property debugging constructs in the administrative- and advertisement-installation sequences if need be.

  也许还有一些用于测试目的的条件:

  And maybe a couple of further conditions for testing purposes:

  • "NOT Installed AND NOT WIX_UPGRADE_DETECTED"
  • "NOT Installed AND NOT REMOVE~="ALL""
  • "NOT Installed AND NOT WIX_UPGRADE_DETECTED"
  • "NOT Installed AND NOT REMOVE~="ALL""

  然后一些由于复杂性而需要进行测试的内容( 不是我的条件，它们来自这里 ):

  And then some that warrant testing due to complexity (not my conditions, they are from here):

  • Installed AND (NOT REMOVE="ALL" OR UPGRADINGPRODUCTCODE)
  • NOT Installed OR Installed AND (NOT REMOVE="ALL" OR UPGRADINGPRODUCTCODE)
  • Installed AND (NOT REMOVE="ALL" OR UPGRADINGPRODUCTCODE)
  • NOT Installed OR Installed AND (NOT REMOVE="ALL" OR UPGRADINGPRODUCTCODE)

  我希望这是一个明确的概念.我有一个用于此类属性调试的VBScript，但它太大且凌乱，无法放在此处.

  I hope that was a clear concept. I have a VBScript for such property debugging, but it is too large and messy to put here.