什么可以导致MSI组件请求状态为空?

时间:2016-06-16 17:13:08

标签: windows-installer installshield

在InstallShield 2015中创建基本MSI安装,我们正在将文件部署到由我们也创建的另一个基本MSI安装程序创建的目录中。我不确定这条信息是否相关或者我没想到的其他变量可能是相关的。但这适用于新安装,并将所有文件传递到我们想要的目录中。但升级其他安装然后尝试升级此安装后,由于某些原因我无法解释(并且所有文件都有更新的版本),并且日志不是&# 39; t帮助很多。我最关心文件PublishRS.exe。这是日志中第一次出现的情况:

Action 11:48:16: InstallValidate. Validating install
Action start 11:48:16: InstallValidate.
01]: Note: 1: 2205 2:  3: Shortcut 
MSI (s) (40:08) [11:48:16:201]: Note: 1: 2205 2:  3: Class 
MSI (s) (40:08) [11:48:16:201]: Note: 1: 2205 2:  3: TypeLib 
 (40:08) [11:48:16:200]: Feature: RSST; Installed: Local;   Request: Local;   Action: Local
MSI (s) (40:08) [11:48:16:200]: Component: PublishRS.exe; Installed: Local;   Request: Null;   Action: Null
MSI (s) (40:08) [11:48:16:200]: Component: FSReportService.asmx; Installed: Local;   Request: Null;   Action: Null

日志中对该文件的唯一其他引用是在以后尝试执行它时由于文件未更新而失败。

任何人都可以帮忙解释我如何确定PublishRS.exe未被复制的原因吗?我认为它与Request: Null有关。真正令人烦恼和无益的是,通常日志会说明为什么它没有复制文件,比如,文件已经存在并且没有旧版本或其他东西,但这里我一无所获。所以关于它为什么不会复制的大多数解释都会消失。在阅读Msiexec REINSTALL=ALL REINSTALLMODE=vamus not reinstalling anything后,我确实检查过我们没有更改任何组件,并确认了它。所以我很难过。升级安装可能导致此组件Request: Null(组件 包含在请求为RSST的{​​{1}}功能中)的原因是什么?

修改: https://www.evernote.com/shard/s269/sh/a193db0f-df06-4bd1-bf49-bca83d12e979/1f825266b645077517cb68d2e159cc67的错误/旧日志 - 除了与旧评论进行比较外,不要查看此日志。它不是实际问题过程的表示。

MSIENFORCEUPGRADECOMPONENTRULES无效,并包含在此日志中。

编辑2:我发现安装在修复模式下运行正常。我想可能有一些我不了解升级的事情。为什么升级会以不同于维修的方式处理组件?就MSI而言, 升级/更新是什么?它与使用较新文件的修复不一样吗?

编辑3:我之前提供的日志似乎不是最好的例子。我有一个更纯的日志,显示命令行包含IS_MINOR_UPGRADE。对困惑感到抱歉。请查看此日志,而不是前面提到的日志: https://www.evernote.com/shard/s269/sh/222a67cb-f237-49fb-88f3-1f882f9d762c/5cb19f1c7b86b344299ebf2c6c29ab89

2 个答案:

答案 0 :(得分:0)

日志不是安装日志。例如它说"跳过RemoveExistingProducts动作:当前配置是维护模式或卸载"和"组件:PublishRS.exe;已安装:本地;要求:无效;行动:空虚"意味着组件已经安装,操作是维护"什么都不做"所以行动是空的。 MSI没有进行升级,这意味着ProductCode尚未更改,并且存在重要的升级逻辑。

如果你打算进行Windows Installer主要升级,那么从帖子中就不清楚了,但如果是这样,那么新的MSI必须有一个新的ProductCode,相同的UpgradeCode,一个版本在第一个增加三位数和FindRelatedProducts和RemoveExistingProducts在MSI文件中排序。

您可能正在考虑使用相同的ProductCode(和递增版本)重新安装更改的MSI的次要更新,但这需要包含REINSTALL = ALL REINSTALLMODE = vomus的命令行安装(并且不建议使用vamus)。然而,InstallShield似乎正在控制底层MSI的安装方式,因此它也不清楚它认为它正在做什么类型的更新或者InstallShiel提供的最终命令,但是这个词的指示和使用"升级"意味着它是一次重大升级。

答案 1 :(得分:0)

似乎摆弄UI序列可能会带来灾难性的后果。我们需要在升级过程中提示一些信息,我相信通过在“SetupResume”序列中包含一个设计用于设置和维护顺序的对话框,我认为这是用于升级后,我们将InstallShield对话框拉入升级序列,这些升级序列并非设计为该序列的一部分,这会强制安装回到错误模式而不是升级。其中一个InstallShield对话框是调用AddLocal,例如,在升级时可能不会发生这种情况。