什么会导致 MSI 组件请求状态为 Null？
What can cause MSI component request state to be Null?
在 InstallShield 2015 中创建 Basic MSI 安装，我们将文件部署到由我们也创建的另一个 Basic MSI 安装程序创建的目录中。我不确定这条信息是否相关，或者我没有想到的其他变量可能相关。但这适用于新安装，并将所有文件传送到我们想要的目录中。但是在升级另一个安装然后尝试升级这个安装之后，由于某种我无法解释的原因它没有提供任何更新的文件（并且文件都有更新的版本），并且日志没有太大帮助。我最关心的是文件 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有关。真正麻烦和无益的是，通常日志会说明为什么它不复制文件，例如，文件已经存在并且没有旧版本或其他东西，但在这里我什么都没有。所以关于为什么它不会复制的大部分解释都在 window 之外。阅读 Msiexec REINSTALL=ALL REINSTALLMODE=vamus not reinstalling anything 后，我确实检查了我们没有更改任何组件，并确认了这一点。所以我很难过。是什么导致此组件 Request: Null（组件 是 包含在请求为 Local 的 RSST 功能中）？
编辑： Bad/old 在 https://www.evernote.com/shard/s269/sh/a193db0f-df06-4bd1-bf49-bca83d12e979/1f825266b645077517cb68d2e159cc67 登录 -- 除了与旧评论进行比较外，不要查看此日志。它不是实际问题过程的表示。
MSIENFORCEUPGRADECOMPONENTRULES 无效，并包含在此日志中。
编辑 2： 我发现安装在修复模式下运行良好。我认为我可能对升级不了解。为什么升级对组件的处理方式与维修不同？就 MSI 而言， 是 还是 upgrade/update？是不是和用更新的文件修复一样？
编辑3: 看来我之前提供的日志可能不是最好的例子。我有一个更纯粹的日志，显示命令行确实包含IS_MINOR_UPGRADE。对困惑感到抱歉。请查看此日志而不是前面提到的日志：
https://www.evernote.com/shard/s269/sh/222a67cb-f237-49fb-88f3-1f882f9d762c/5cb19f1c7b86b344299ebf2c6c29ab89
日志不是安装日志。例如它说 "Skipping RemoveExistingProducts action: current configuration is maintenance mode or an uninstall" 和 "Component: PublishRS.exe; Installed: Local; Request: Null; Action: Null" 表示该组件已经安装，操作是维护 "do nothing"，因此操作为空。 MSI 没有进行升级，这意味着 ProductCode 没有更改，并且存在主要的升级逻辑。
从 post 中不清楚您是否打算 Windows 安装程序主要升级，但如果是这样，那么新的 MSI 必须有一个新的 ProductCode，相同的 UpgradeCode，一个在MSI 文件中的前三位数字以及 FindRelatedProducts 和 RemoveExistingProducts。
您可能正在考虑使用相同的 ProductCode（和增量版本）重新安装更改后的 MSI 的小更新，但这需要包括 REINSTALL=ALL REINSTALLMODE=vomus 的命令行安装（不推荐使用 vamus）。然而，InstallShield 似乎正在控制底层 MSI 的安装方式，因此也不清楚它认为它在做什么类型的更新或 InstallShiel 提供的最终命令是什么，但 "upgrade" 这个词的指示和使用暗示它是一个重大升级。
似乎摆弄UI序列会带来灾难性的后果。我们需要在升级期间提示输入一些信息，我相信通过在 "SetupResume" 序列中包含我们的一个对话框，该对话框被设计为在设置和维护序列中也能很好地流动，我相信这就是在升级时使用，我们导致 InstallShield 对话框被拉入升级序列，而该对话框并非设计为该序列的一部分，这迫使安装回到错误的模式而不是升级。例如，InstallShield 对话框之一正在调用 AddLocal，这可能不会在升级时发生。
在 InstallShield 2015 中创建 Basic MSI 安装，我们将文件部署到由我们也创建的另一个 Basic MSI 安装程序创建的目录中。我不确定这条信息是否相关，或者我没有想到的其他变量可能相关。但这适用于新安装，并将所有文件传送到我们想要的目录中。但是在升级另一个安装然后尝试升级这个安装之后，由于某种我无法解释的原因它没有提供任何更新的文件（并且文件都有更新的版本），并且日志没有太大帮助。我最关心的是文件 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有关。真正麻烦和无益的是，通常日志会说明为什么它不复制文件，例如，文件已经存在并且没有旧版本或其他东西，但在这里我什么都没有。所以关于为什么它不会复制的大部分解释都在 window 之外。阅读 Msiexec REINSTALL=ALL REINSTALLMODE=vamus not reinstalling anything 后，我确实检查了我们没有更改任何组件，并确认了这一点。所以我很难过。是什么导致此组件 Request: Null（组件 是 包含在请求为 Local 的 RSST 功能中）？
编辑： Bad/old 在 https://www.evernote.com/shard/s269/sh/a193db0f-df06-4bd1-bf49-bca83d12e979/1f825266b645077517cb68d2e159cc67 登录 -- 除了与旧评论进行比较外，不要查看此日志。它不是实际问题过程的表示。
MSIENFORCEUPGRADECOMPONENTRULES 无效，并包含在此日志中。
编辑 2： 我发现安装在修复模式下运行良好。我认为我可能对升级不了解。为什么升级对组件的处理方式与维修不同？就 MSI 而言， 是 还是 upgrade/update？是不是和用更新的文件修复一样？
编辑3: 看来我之前提供的日志可能不是最好的例子。我有一个更纯粹的日志，显示命令行确实包含IS_MINOR_UPGRADE。对困惑感到抱歉。请查看此日志而不是前面提到的日志： https://www.evernote.com/shard/s269/sh/222a67cb-f237-49fb-88f3-1f882f9d762c/5cb19f1c7b86b344299ebf2c6c29ab89
日志不是安装日志。例如它说 "Skipping RemoveExistingProducts action: current configuration is maintenance mode or an uninstall" 和 "Component: PublishRS.exe; Installed: Local; Request: Null; Action: Null" 表示该组件已经安装，操作是维护 "do nothing"，因此操作为空。 MSI 没有进行升级，这意味着 ProductCode 没有更改，并且存在主要的升级逻辑。
从 post 中不清楚您是否打算 Windows 安装程序主要升级，但如果是这样，那么新的 MSI 必须有一个新的 ProductCode，相同的 UpgradeCode，一个在MSI 文件中的前三位数字以及 FindRelatedProducts 和 RemoveExistingProducts。
您可能正在考虑使用相同的 ProductCode（和增量版本）重新安装更改后的 MSI 的小更新，但这需要包括 REINSTALL=ALL REINSTALLMODE=vomus 的命令行安装（不推荐使用 vamus）。然而，InstallShield 似乎正在控制底层 MSI 的安装方式，因此也不清楚它认为它在做什么类型的更新或 InstallShiel 提供的最终命令是什么，但 "upgrade" 这个词的指示和使用暗示它是一个重大升级。
似乎摆弄UI序列会带来灾难性的后果。我们需要在升级期间提示输入一些信息，我相信通过在 "SetupResume" 序列中包含我们的一个对话框，该对话框被设计为在设置和维护序列中也能很好地流动，我相信这就是在升级时使用，我们导致 InstallShield 对话框被拉入升级序列，而该对话框并非设计为该序列的一部分，这迫使安装回到错误的模式而不是升级。例如，InstallShield 对话框之一正在调用 AddLocal，这可能不会在升级时发生。