InstallScript 项目在升级时出现错误 1706

Question

我有一个在InstallShield 2010 中从头开始编写的InstallScript 项目。它包含三个本机InstallShield 对象和四个包装MSM 文件的InstallShield 合并模块持有者对象。

当我最初测试该项目时，它在干净的环境中安装得很好，但是当我尝试升级到较新的版本时，四个合并模块持有者对象中的每一个都生成了“错误 1706。找不到产品 XXXX 的有效源”消息。

我在网上做了一些挖掘，发现这是一个 Windows Installer 错误，发生这种情况是因为即使原始安装介质消失后，MSI 文件也必须存在于计算机上。确保这一点的推荐方法是在“合并模块持有者对象”属性对话框中勾选“在本地缓存 msi 包”复选框。

我勾选了所有四个合并模块的复选框并重新测试，但这并没有解决问题。然后我查看了这些合并模块实际放置在硬盘上的位置。属性对话框显示 ，在运行时解析为 C:\Program Files\InstallShield Installation Information\{Product GUID}。查看测试机器，似乎所有四个合并模块都写入同一个位置，从而覆盖彼此的 MSI 文件。

为了解决这个问题，我编辑了每个合并模块，将其自身缓存到唯一的路径 \{Name}。我再次编译并测试，我可以看到每个合并模块现在确实将其自身保存到一个唯一的子文件夹中。但是，当我升级时，所有四个错误 1706 消息仍然出现。

有人有什么想法吗？我确信我错过了一些明显的东西，但它似乎没有记录在任何地方。 :-)

更新：

根据 InstallShield 论坛上的大量帖子，InstallShield 每次构建 InstallScript 项目时都会为每个嵌入式 MSI 生成一个全新的产品 G​​UID。在更新过程中，InstallShield 引擎会用较新的版本覆盖目标计算机上缓存的每个 MSI 文件，但是当执行它们时，Windows Installer 会说“嘿，这是一个新产品，旧产品的 MSI 在哪里，以便我可以卸载它吗？”，因此出现错误。

是否可以告诉 InstallShield 在每次构建时不要为每个嵌入式 MSI 重新生成产品 GUID？这种行为肯定是对将合并模块嵌入 InstallScript 项目的整个想法的嘲笑吗？ :-(

Answer 1

我通过以下方法完成了这项工作：

1. 获取与我们已有的 MSM 相对应的独立 MSI 设置。幸运的是，这对他们所有人来说都是可能的。
2. 将 MSI 作为可安装组件包含在 InstallScript 项目中，安装到目标上合适的临时位置。
3. 在相关的 _Installed 事件中，外壳到 msiexec.exe 并使用 /i 和 运行 MSI 文件/qb 开关。
4. 在相关的 _UnInstalling 事件中，外壳到 msiexec.exe 并使用 /x 开关运行 MSI 文件。

这感觉有点“错误”，但效果很好，所以我很乐意就此结束，除非有人有更好的想法。