WIX 安装程序:阻止在 Windows Server 2012 R2 上安装 [英] WIX Installer: Prevent installation on Windows Server 2012 R2

问题描述

我有一个只能安装在 Windows Server 2016(或更高版本)上的 WIX 项目.

I have a WIX project that must only be installed on Windows Server 2016 (or newer).

查看 Microsoft 文档，VersionNT 用于:

Looking at Microsoft documentation, VersionNT for:

Windows Server 2016 是 603，Windows Server 2012 是 602.

Windows Server 2016 is 603, Windows Server 2012 is 602.

从未提到过用于 Windows Server 2012R2 的 VersionNT.

The VersionNT for Windows Server 2012R2 has never been mentioned.

当我使用下面的代码行时:

When I use below line of code:

<Condition Message="!(loc.RequireServer2016)"><![CDATA[INSTALLED OR (VersionNT>= 603)]]></Condition>

它仍然允许我在 Windows Server 2012R2 上安装.

it still lets me install on Windows Server 2012R2.

如何将我的软件安装限制为仅 Server 2016 并阻止它安装在 Server 2012R2 上?

How can I limit the installation of my software to only Server 2016 and prevent it from installing on Server 2012R2?

推荐答案

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 查看器之一(靠近底部):如何比较两个(或更多)MSI文件的内容?

无版本:在 Windows 10 中检测操作系统版本的方式发生了巨大变化.我不知道这是否也会影响 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 根本不一定报告操作系统的正确版本！
• 请阅读此答案，而不是我在这里重复:在 installshield 上未检测到 Windows 10.

• 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 的真正值是什么，我将使用两种方法之一来在运行时检查属性.后一个选项(日志记录)通常更快更容易，而第一个选项还允许您在设置运行时评估复杂条件，并使用 Session.EvaluateCondition 方法 (我在条件满足时使用此方法调用复杂且令人困惑，我想要一些运行时证明它们的行为符合我的预期):

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 中的真正自定义操作源 - 在您编译源的编译自定义操作中并非如此from 可能不可用(由于所有技术事物固有的混乱 - 在现实世界中) - 这确实非常糟糕.
• 另一个好处是 VBScript 的简单性，以及企业应用程序打包者如何比 C++/C# 更好地掌握复杂性.但总体脚本自定义操作总是会导致 Rob 提到的问题(防病毒阻止、糟糕的调试和缺乏正确错误处理的编码乏善可陈).
• 至关重要的是，您将在企业部署方案中控制安全软件/防病毒.您可以以合乎逻辑的方式处理问题并进行调整，直到包可靠地部署.
• 最后，企业台式机是 SOE - 标准化平台，其可变性远低于普通 PC(其状态可能更加多样化，因此会出现更多部署问题).
• 真正的问题基本上是自定义操作，它们很容易出错:为什么限制在我的 WiX/MSI 设置中使用自定义操作是个好主意?我猜想的信息比你需要的多得多.故事的寓意对我来说是:使用最快完成工作的任何方法，但不要认为脚本足以用于生产代码以供全球分发.
• 对于企业部署，应消除临时脚本自定义操作，转而采用经过良好测试的 C++ 自定义操作，并由自定义 MSI 表驱动，完全支持回滚，从而完整声明安装期间应发生的情况.

• 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 的值.我喜欢为所有设置启用日志记录，如下所述:installsite.org 了解如何进行日志记录 - 请参阅机器上的所有设置全局"部分).尽管性能受到影响，我总是在 TEMP 文件夹 中准备好一个日志文件以进行调试.相同的链接也将向您展示如何仅为单个安装制作临时日志(本质上是: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).

<小时>

Property Debugger Demo:这超出了您的要求，但我认为您可能很难为您的服务器部署调试此问题和类似问题，我想快速演示如何在 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 自定义动作可以根据您的需要以不同的顺序和不同的位置插入.属性值可能会有所不同，具体取决于您的 sequencing (!) 以及您所处的安装模式(install、uninstall、repair、modify、self-repair、major upgrade(涉及安装一个MSI，卸载一个MSI), minor upgrade, minor upgrade patch, major upgrade patchetc...) 以及是否运行在deferred 或 immediate context 或者您是在 silently 还是 interactively 运行，以及我忘记的任何变量 - 很多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:

• 未安装且未 WIX_UPGRADE_DETECTED"
• "未安装且未移除~="ALL""

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

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

• 已安装 AND(不是 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.

这篇关于WIX 安装程序:阻止在 Windows Server 2012 R2 上安装的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！