我在InstallShield 2010中从头到尾写了一个InstallShield项目。它包含三个本机InstallShield对象和四个InstallShield合并模块Holder对象,这些对象包装了MSM文件。
当我最初测试该项目时,它在干净的环境中安装得很好,但是当我尝试升级到更新版本时,四个对象中的每一个都产生了一个"Error 1706。无法为产品XXXX找到有效的源“消息。
我在网络上做了一些调查,发现这是一个Windows安装程序错误,这是因为即使在原始安装媒体消失之后,MSI文件也必须存在于机器上。建议的确保方法是在对象属性对话框中勾选“缓存msi包本地”复选框。
我选中了所有四个合并模块的框,并进行了重新测试,但这并没有解决问题。然后,我查看了这些合并模块实际上放在硬盘上的位置。属性对话框是<DISK1TARGET>,它在运行时解析为C:\Program Files\InstallShield Installation Information\{Product }。看看测试机器,似乎所有四个合并模块都写到了同一个地方,从而覆盖了彼此的MSI文件。
为了解决这个问题,我编辑了每个合并模块,以将自己缓存到唯一的路径<DISK1TARGET>\{Name}。我再次编译和测试,我可以看到每个合并模块现在确实将自己保存到一个唯一的子文件夹中。然而,当我升级时,所有四条错误1706消息仍然会出现。
有人有什么想法吗?我肯定我漏掉了一些显而易见的东西,但它似乎没有被记录在任何地方。:-)
更新:
根据InstallShield论坛上的许多帖子,似乎每次构建InstallScript项目时,InstallShield都会为每个嵌入式MSI生成一个全新的产品GUID。在更新过程中,InstallShield引擎用较新的版本覆盖目标计算机上缓存的每个MSI文件,但是当涉及到执行这些文件时,Windows说:“嘿,这是一个新产品,旧产品的MSI在哪里,这样我就可以卸载它了?”
是否可以告诉InstallShield不要在每次构建时为每个嵌入式MSI重新生成产品GUID?这种行为无疑是对将合并模块嵌入到InstallScript项目的整个想法的嘲弄?
发布于 2010-07-12 09:38:37
我是通过这样做的:
<feature>_Installed事件中,msiexec.exe,并使用/i和/qb开关运行MSI文件。在相关的<feature>_UnInstalling事件中,msiexec.exe并使用/x开关运行MSI文件。H 215/code>G 216这感觉有点“不对”,但效果很好,所以我很高兴离开它,除非有人有更好的想法。
https://stackoverflow.com/questions/3110029
复制相似问题