Wix 升级进入维护模式,从不升级 [英] Wix upgrade goes into maintenance mode and never does upgrade

查看:40
本文介绍了Wix 升级进入维护模式,从不升级的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在运行 Wix 3.11.1,当尝试升级时,升级进入维护模式并在添加/删除程序列表中留下两个条目.

I am running Wix 3.11.1 and when trying to do an upgrade the upgrade goes into maintenance mode and leaves two entries in Add/Remove programs list.

Product.wxs 的简短版本具有以下内容:

A short version of Product.wxs has the following:

 <Product Id="*"  Name="Boo" Language="1033" Version="1.1.0.0" Manufacturer="Foo"
          UpgradeCode="PUT-GUID-HERE">

    <Package InstallerVersion="200"  Compressed="yes" InstallScope="perMachine"/>

<MajorUpgrade AllowDowngrades="no" AllowSameVersionUpgrades="yes" 
              DowngradeErrorMessage="!(loc.NewerVersionInstalled)" />

升级代码:3F55CE54-8409-4918-9906-D8AD18794BFC

Upgrade Code: 3F55CE54-8409-4918-9906-D8AD18794BFC

产品和包装代码是:

1.0

产品代码 FC49F622-02E6-40D9-ACD9-92BDD4AF5979

Product Code FC49F622-02E6-40D9-ACD9-92BDD4AF5979

封装代码 6C49FAA1-5B11-4173-80A7-A7B3FA4313AE

Package Code 6C49FAA1-5B11-4173-80A7-A7B3FA4313AE

1.1

产品代码 4871555F-F369-4159-9EF0-4BBDF07B6842

Product Code 4871555F-F369-4159-9EF0-4BBDF07B6842

封装代码 3594D7C2-D5AC-4A41-A8C6-6E3D63C6ACA0

Package Code 3594D7C2-D5AC-4A41-A8C6-6E3D63C6ACA0

当我运行带有日志记录的安装程序时,我得到如下所示的日志信息.当升级代码相同而产品和包装代码不同,并且版本在前三位数字中递增时,我认为应该发生升级,但事实并非如此.此外,这两个版本都是针对每台机器的,因此不应停止删除以前的版本.日志显示维护模式,从不执行删除以前的版本.我在 msi 中有一个升级表,它显示了 1.1 的最大值和 WIX_UPGRADE_DETECTED 作为操作.有谁知道什么会导致它进入维护模式而不是进行重大升级?

When I run the installer with logging I get the log information shown below. When the upgrade code is the same and product and package codes are different, and the version is incremented in the first three digits I thought an upgrade should occur but is isn't. Also both versions are per-machine so that should not stop the removal of previous version. The log shows maintenance mode and never performs removal of previous version. I have an upgrade table in the msi and it shows the max value of 1.1 and WIX_UPGRADE_DETECTED as the action. Does anyone know what would cause this to enter maintenance mode rather do a major upgrade?

日志文件

    MSI (s) (68:9C) [15:04:38:423]: Doing action: RemoveExistingProducts
Action 15:04:38: RemoveExistingProducts. Removing applications
Action start 15:04:38: RemoveExistingProducts.
RemoveExistingProducts: Application: {FC49F622-02E6-40D9-ACD9-92BDD4AF5979}, Command line: UPGRADINGPRODUCTCODE={4871555F-F369-4159-9EF0-4BBDF07B6842} CLIENTPROCESSID=8344 CLIENTUILEVEL=0 MSICLIENTUSESEXTERNALUI=1 REMOVE=ALL
MSI (s) (68:BC) [15:04:38:423]: Resetting cached policy values
MSI (s) (68:BC) [15:04:38:423]: Machine policy value 'Debug' is 0
MSI (s) (68:BC) [15:04:38:423]: ******* RunEngine:
           ******* Product: {FC49F622-02E6-40D9-ACD9-92BDD4AF5979}
           ******* Action: 
           ******* CommandLine: **********
MSI (s) (68:BC) [15:04:38:423]: Note: 1: 2203 2: C:\WINDOWS\Installer\inprogressinstallinfo.ipi 3: -2147287038 
MSI (s) (68:BC) [15:04:38:423]: Machine policy value 'LimitSystemRestoreCheckpointing' is 0
MSI (s) (68:BC) [15:04:38:423]: Note: 1: 1717 2: Boo 
MSI (s) (68:BC) [15:04:38:423]: Calling SRSetRestorePoint API. dwRestorePtType: 1, dwEventType: 102, llSequenceNumber: 0, szDescription: "Removed Boo".
MSI (s) (68:BC) [15:04:38:439]: The call to SRSetRestorePoint API succeeded. Returned status: 0, llSequenceNumber: 45.
MSI (s) (68:BC) [15:04:38:439]: End dialog not enabled
MSI (s) (68:BC) [15:04:38:439]: Original package ==> C:\WINDOWS\Installer\1179bb4.msi
MSI (s) (68:BC) [15:04:38:439]: Package we're running from ==> C:\WINDOWS\Installer\1179bb4.msi
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: Uninstall Flags override found.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: Uninstall VersionNT override found.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: Uninstall ServicePackLevel override found.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: looking for appcompat database entry with ProductCode '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: no matching ProductCode found in database.
MSI (s) (68:BC) [15:04:38:439]: Machine policy value 'DisablePatch' is 0
MSI (s) (68:BC) [15:04:38:439]: Machine policy value 'AllowLockdownPatch' is 0
MSI (s) (68:BC) [15:04:38:439]: Machine policy value 'DisableLUAPatching' is 0
MSI (s) (68:BC) [15:04:38:439]: Machine policy value 'DisableFlyWeightPatching' is 0
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: looking for appcompat database entry with ProductCode '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: no matching ProductCode found in database.
MSI (s) (68:BC) [15:04:38:439]: Transforms are not secure.
MSI (s) (68:BC) [15:04:38:439]: Command Line: UPGRADINGPRODUCTCODE={4871555F-F369-4159-9EF0-4BBDF07B6842} CLIENTPROCESSID=8344 CLIENTUILEVEL=0 MSICLIENTUSESEXTERNALUI=1 REMOVE=ALL 
MSI (s) (68:BC) [15:04:38:439]: PROPERTY CHANGE: Adding PackageCode property. Its value is '{6C49FAA1-5B11-4173-80A7-A7B3FA4313AE}'.
MSI (s) (68:BC) [15:04:38:439]: Product Code passed to Engine.Initialize:           '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'
MSI (s) (68:BC) [15:04:38:439]: Product Code from property table before transforms: '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'
MSI (s) (68:BC) [15:04:38:439]: Product Code from property table after transforms:  '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'
MSI (s) (68:BC) [15:04:38:439]: Product registered: entering maintenance mode

更新:

这确实是一个捆绑安装.我认为 msi 是罪魁祸首,因为我认为 Wix 包会使用 msiexec 来执行卸载.

This is indeed a bundle install. I looked at the msi being the culprit because I thought that Wix bundle would use msiexec to perform the uninstall.

在我们的构建中,我们使用搜索词0.0.0.0"作为包中的版本,然后使用 msi 替换正确的版本,并在构建结束时恢复 Bundle.wxs 和产品.wxs.

In our build we use the search term "0.0.0.0" for the version in the bundle and msi then we do a replace with the correct version, and at the end of the build we revert the Bundle.wxs and Product.wxs.

当安装程序正在处理时,开发人员必须在构建文件中注释掉恢复,以便处理文件.开发人员完成后,他们需要将版本设置回0.0.0.0".在其中一个安装程序签入中,有人不得不忘记改回0.0.0.0".

When the installer is being worked on the developer must comment out the revert, in the build file, in order to work on the files. When the developer is done they need to set the version back to "0.0.0.0". In one of the installer checkins someone had to forgotten to change back to "0.0.0.0".

我自己尝试了两个版本的 msi,升级确实删除了原始安装的条目.然而,捆绑升级仍然留下第二个条目,即使版本是正确的.

I tried the msi for the two versions by themselves, and upgrade did indeed remove the entry for the original install. However the bundle upgrade still leaves second entry, even though the version is correct.

推荐答案

Short Version

许多实例:我认为您的软件包的许多版本彼此重叠"安装在许多实例中 - 其中一些对 是隐藏的添加/删除程序,因为在(某些)包中指定了 ARPSYSTEMCOMPONENT=1 设置.已安装的实例之一与您尝试安装的软件包具有相同的产品代码 - 这会触发维护模式 - 因为该产品代码已注册为已安装.

Short Version

Many Instances: I think there are many versions of your package installed in many instances "on top of each other" - some of which are hidden from Add / Remove Programs because of the ARPSYSTEMCOMPONENT=1 setting being specified in (some of) the package(s). One of the installed instances has the same product code as the package you are trying to install - this triggers maintenance mode - since the product code is already registered as installed.

包代码混淆?:也有可能您安装了两个或多个具有相同包代码的相同 MSI 版本(与产品代码相反).这总是会导致神秘的问题 - 例如您在维护模式下看到的问题(相同的包 GUID 意味着根据定义,两个不同的 MSI 文件将被视为同一个文件 - 因为 GUID 是相同的 - X 文件随之而来为 msiexec.exe 在你背后运行,从旧的、缓存的 MSI 运行,而不是你的新 MSI).

Package Code Confusion?: It is also possible that you have installed two or more versions of the same MSI with identical package codes (as opposed to product codes). This always causes mysterious problems - for example the problem you are seeing with maintenance mode (identical package GUIDs mean two different MSI files will be treated as the same file by definition - since the GUIDs are the same - X-Files ensues as msiexec.exe goes behind your back and runs from the old, cached MSI and not your new MSI).

捆绑?:正如 Phil 所写,这也可能是 WiX 捆绑问题.也许先尝试底部的脚本以获得已安装内容的完整列表 - 是否隐藏.

Bundle?: As Phil writes, it could be a WiX bundle problem as well. Maybe try the script towards the bottom first to get a full list of what is installed - hidden from view or not.

可能的原因:您似乎正在设置 ARPSYSTEMCOMPONENT = 1 这将隐藏添加/删除程序中的设置(ARP).据我所知,日志中有许多包装和产品代码与您在问题中指定的不匹配.您似乎在系统上安装了多个较旧的测试版本,这些版本也可能对 ARP 隐藏,但仍安装在盒子上.不知道为什么你说当前版本显示在 ARP 中?如果设置了 ARPSYSTEMCOMPONENT,则不应这样做.

Possible Cause: It seems you are setting ARPSYSTEMCOMPONENT = 1 which will hide the setup from Add / Remove Programs (ARP). As far as I can see there are numerous package and product codes in the log that do not match the ones you specify in your question. It seems you may have several older, test versions installed on the system that could also be hidden from ARP, but are still installed on the box. Not sure why you say the current version shows up in ARP though? With ARPSYSTEMCOMPONENT set it should not do so.

Virtuals:正如一贯的格言:当您看到奇怪的问题时在虚拟设备上进行测试 - 以确定您的测试环境是否不干净.虚拟测试对我来说至关重要,但我经常做得太晚.

Virtuals: As the motto always goes: test on virtuals when you see weird problems - in order to determine if you have an unclean test environment. Virtuals testing is crucial for me, but I often do it too late.

MSDN:ARPSYSTEMCOMPONENT.

更新:

罪魁祸首机制:当您将产品代码设置为自动生成时,每个版本都可以在不显示维护模式的情况下进行安装 - 即使没有编写升级表根本.当您将此与隐藏添加/删除程序结合起来时,您突然无法分辨安装了哪些先前版本.在您进行测试安装时,相互重叠安装的重复项可能会堆积起来.

Culprit Mechanism: When you set the product code to auto-generate, every build will be able to install without maintenance mode showing up - even without authoring the upgrade table at all. When you combine this with hiding from Add / Remove Programs you suddenly can't tell what prior versions were installed. Duplicates installed on top of each other could pile up as you do test installs.

由于您似乎确实会自动生成产品代码,因此您永远不会遇到当前问题:维护模式.这让我怀疑存在包代码重复问题.或者像 Phil 所建议的捆绑问题.我对捆绑的经验太少.可能是捆绑错误吗?甚至是 WiX 错误?

Since you do seem to auto-generate the product code, you should never experience the current problem: maintenance mode. This leads me to suspect a package code duplication problem. Or a bundle problem, as suggested by Phil. I have too little experience with bundles. Could it be a bundle bug? Or even a WiX bug?

手动卸载:也许可以尝试使用您可以在此处找到的 VBScript 导出系统上当前安装的 MSI 产品代码列表(无论它们是否隐藏)): 如何找到已安装 MSI 设置的产品 G​​UID?(朝底部,在替代工具,第 3 部分".

更新:请参阅下面的内联和修改后的脚本版本.

获得列表后,尝试使用以下方法卸载不需要的测试包:

Once you have the list, try to uninstall the undesired test packages using:

msiexec.exe/x [产品代码]

继续卸载,直到你有一个干净的盒子".

keep going with uninstalls until you have a "clean box".

完整版本传播的主要升级:或者,您可以为升级表设置广泛的版本范围(最小/最大版本),看看是否可以卸载所有现有版本定期进行重大升级.坦率地说,我从未花时间使用主要升级来测试卸载多个先前版本,但据我所知它应该可以工作.注意!:如果您有包代码重复,我认为这行不通.

卸载相关产品:显示如何卸载共享相同升级代码的所有产品的另一个答案.请注意在静默模式下运行时可能会自动触发重新启动的免责声明:Powershell:通过升级代码卸载应用程序.

按产品名称卸载:不太明智,但我只会添加一个链接以便妥善保管.以下是按产品名称卸载 MSI 包的方法:使用 msiexec 卸载应用程序时是否有替代 GUID 的方法?

更新:想想看,让我在上面的链接脚本中添加一些内容 - 这会将标题、发布者和包代码添加到导出中.这个脚本应该显示所有已安装的包,包括那些隐藏在添加/删除程序中的包(如果你还需要升级代码,那么由于技术原因这会稍微复杂一些,此处描述了如何以笨拙的方式完成此操作 - 该链接又包含有关如何使用 Powershell 检索升级代码的进一步链接):>

UPDATE: Come to think of it, let me inline the linked script above with a couple of additions - this adds headers and publisher and package code to the export. This script should show all installed packages, including those hidden from Add / Remove Programs (if you also need Upgrade Code, then this is a little more complicated for technical reasons, here is a description of how it can be done in a clunky way - that link in turn has further links for how to retrieve upgrade codes with Powershell):

' Retrieve all ProductCodes (with ProductName and ProductVersion)

Set fso = CreateObject("Scripting.FileSystemObject")
Set output = fso.CreateTextFile("msiinfo.csv", True, True)
Set installer = CreateObject("WindowsInstaller.Installer")

output.writeline ("Product Code,Product Name,Product Version,Package Code, Publisher")

On Error Resume Next ' we ignore all errors

For Each product In installer.ProductsEx("", "", 7)
   productcode = product.ProductCode
   name = product.InstallProperty("ProductName")
   version=product.InstallProperty("VersionString")
   packagecode=product.InstallProperty("PackageCode")
   publisher=product.InstallProperty("Publisher")

   output.writeline (productcode & ", " & name & ", " & version  & ", " & packagecode & ", " & publisher)
Next

output.Close

使用:

  • 复制脚本并粘贴到桌面上的 *.vbs 文件中,然后尝试通过双击运行它.您的桌面必须是可写的,或者您可以使用任何其他可写位置.
  • 输出文件在您运行脚本的文件夹中创建(文件夹必须是可写的).输出文件名为 msiinfo.csv.
  • 双击要在电子表格应用程序中打开的文件,在导入时选择逗号作为分隔符 - 或者 - 只需在记事本或任何文本查看器中打开文件.
  • 电子表格中的内容应按列格式化,如果不是,请手动打开文件并导入文件,选择逗号作为 CSV 文件的分隔符(逗号分隔值).这样做将产生完整的电子表格功能,例如按列排序 - 例如 Publisher - 这样您就可以看到彼此相邻的所有设置.

这篇关于Wix 升级进入维护模式,从不升级的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆