我在InstallShield 2010中有一个从头开始编写的InstallScript项目。它包含三个本机InstallShield对象和四个包装MSM文件的InstallShield合并模块持有者对象。
当我最初测试项目时,它在干净的环境中安装得很好,但是当我尝试升级到更新的版本时,四个合并模块持有者对象中的每一个都产生了“错误1706.产品没有找到有效的来源XXXX“消息。
我在网上进行了一些挖掘,发现这是一个Windows Installer错误,因为即使在原始安装媒体消失后,MSI文件也必须存在于计算机上。建议的方法是在合并模块持有者对象属性对话框中选中“在本地缓存msi包”复选框。
我为所有四个合并模块勾选了该框并重新测试,但这并没有解决问题。然后我看看这些合并模块实际放在硬盘上的位置。属性对话框显示<DISK1TARGET>
,在运行时解析为C:\Program Files\InstallShield Installation Information\
{Product GUID} 。看看测试机器,好像所有四个合并模块都写到同一个地方,从而覆盖了彼此的MSI文件。
为了解决这个问题,我编辑了每个合并模块,将其自身缓存到一个唯一路径<DISK1TARGET>\
{Name} 。我再次编译和测试,我可以看到每个合并模块现在确实将自己保存到一个独特的子文件夹。但是,升级时,所有四条Error 1706消息都仍然出现。
有没有人有任何想法?我确定我遗漏了一些明显的东西,但似乎没有记录在任何地方。 : - )
更新
根据InstallShield论坛上的大量帖子,每次构建InstallScript项目时,InstallShield似乎都会为每个嵌入式MSI生成一个全新的产品GUID。在更新过程中,InstallShield引擎会使用较新版本覆盖目标计算机上缓存的每个MSI文件,但是当执行它们时,Windows Installer会说“嘿,这是一个新产品,旧产品的MSI在哪里,所以我可以卸载吗?“,因此错误。
是否可以告诉InstallShield在每次构建时不为每个嵌入式MSI重新生成产品GUID?当然这种行为嘲弄了将合并模块嵌入到InstallScript项目中的整个想法? : - (
答案 0 :(得分:0)
我的工作是:
<feature>_Installed
事件中,shell msiexec.exe
并使用/i
和/qb
开关运行MSI文件。<feature>_UnInstalling
事件中,shell msiexec.exe
并使用/x
开关运行MSI文件。这感觉有些“错误”,但效果很好,所以除非有人有更好的想法,否则我很乐意留下它。