1

我有一个在 InstallShield 2010 中从头开始编写的 InstallScript 项目。它包含三个本机 InstallShield 对象和四个包装 MSM 文件的 InstallShield Merge Module Holder Objects。

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

我在网上做了一些挖掘，发现这是一个 Windows Installer 错误，它的发生是因为即使在原始安装介质消失后，MSI 文件也必须存在于机器上。确保这一点的推荐方法是在 Merge Module Holder Object 属性对话框中勾选“本地缓存 msi 包”复选框。

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

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

有没有人有任何想法？我确定我遗漏了一些明显的东西，但它似乎没有在任何地方记录。:-)

更新：

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

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

4

1 回答 1

0

我得到了这个工作：

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

这感觉有点“错误”，但效果很好，所以除非有人有更好的想法，否则我很乐意将其保留。

于 2010-07-12T09:38:37.153 回答