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

问题描述

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

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 文件中.查看中是否有条目启动条件表.
• 我假设您有 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 根本不需要报告正确的操作系统版本！
• 请阅读这个答案，而不是我在这里重复: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 在您的设置中的实际值，我将使用两种方法之一来在运行时检查属性.后一个选项(日志记录)通常更快更容易，而第一个选项还允许您在设置运行时评估复杂条件，并在运行时使用 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. Property Debugger 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.

Logging:只需为设置创建一个日志文件并检查其中的 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 自定义操作可以根据需要插入不同的序列和不同的位置.属性值可能会有所不同，具体取决于您的排序 (!) 以及您所处的安装模式(install、uninstall、修复、修改、自修复、重大升级(涉及安装一个MSI，卸载一个MSI)、minor upgrade、minor upgrade patch、major upgrade patchetc...) 以及是否运行在deferred 或 immediate context 或者您是静默还是交互式运行，以及我忘记的任何变量 - 很多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""

还有一些由于复杂性而需要进行测试(不是我的条件，它们来自这里a>):

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

• 已安装且(NOT REMOVE="ALL" OR UPGRADINGPRODUCTCODE)
• 未安装或已安装且(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.

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