我们的应用程序之一是 VB6 应用程序,它需要 Tabctl32.ocx。
因此,我将“tabctl32.msm”(其中包含版本 6.1.97.82)添加到基于每台计算机的 Wix 中。当我运行这个每台机器的 MSI 时,它安装了 OCX,并且当我作为管理员登录并启动 VB 应用程序时,该应用程序运行良好。
但是,如果任何具有标准用户权限的人首次登录并启动此 VB 应用程序,则会触发 MSI self 修复。一旦该用户的 self 修复完成,它就会起作用,并且不会再触发该用户的 self 修复。管理员用户不会发生这种 self 修复。
当我使用 Orca 检查 MSI 时,在“ModuleDependency”表中,此 tabctl32 模块与 COMCAT msm 和 OLEAUT32 msm 具有依赖关系,我们也将它们与合并模块一起安装。
我不明白为什么 self 修复不会发生在管理员用户身上,而是发生在标准用户身上?
谁能解释一下这是怎么回事?
最佳答案
这可能与标准用户、管理员用户或 OCX 无关 - 它可能只是不同用户。
如果 MSI 中有任何资源属于特定用户(例如个人文件夹或其他文件夹中面向用户的文件,或者 HKCU 中的注册表项),则第一次安装将安装所有这些资源以进行安装用户。
如果另一个用户登录并使用该应用程序(希望每台计算机安装),则修复触发器(例如使用快捷方式)将注意到该特定用户缺少这些用户项目并将安装它们。这种情况应该只发生一次——如果同一用户重复进行修复,那么情况就更严重了。
无论如何,应用程序事件日志都应该有一个 MsiInstaller 日志条目,其中包含有关产品和缺失组件的一些数据。
这也可能取决于 VB6 应用程序 - 它很旧,没有 list ,因此可能以奇怪的方式与 UAC 交互。例如,如果其行为被虚拟化以使用系统文件夹的\VirtualStore 位置,则很可能需要将选项卡控件重新安装到该虚拟化系统文件夹中。管理员用户不会有同样的问题。
关于vb6 - 通过合并模块安装 Tabctl32 时,非管理员用户会触发 MSI self 修复,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41466224/