通过合并模块安装 Tabctl32 时为非管理员用户触发的 MSI 自我修复 [英] MSI self-repair triggered for the non-admin user when Tabctl32 was installed via merge module

问题描述

我们的一个应用程序是 VB6 应用程序，它需要 Tabctl32.ocx.

One of our applications is VB6 app, which requires Tabctl32.ocx.

所以我将tabctl32.msm"(它包含在版本 6.1.97.82 中)添加到基于每台机器的 Wix.当我运行这个每台机器的 MSI 时，它安装了 OCX，当我以管理员身份登录并启动 VB 应用程序时，应用程序运行良好.

So I added "tabctl32.msm" (which contained it with the version 6.1.97.82) to per-machine based Wix. When I ran this per-machine MSI, it installed that OCX and the application worked fine when I as an admin logged in and launched the VB app.

但是，如果任何具有标准用户权限的人首次登录并启动此 VB 应用程序，则会触发 MSI 自我修复.一旦为该用户完成自我修复，它就起作用了，并且不再为该用户触发自我修复.管理员用户没有发生这种自我修复.

However, if any person with a standard user privileges logged in and launched this VB app for the first time, it triggered an MSI self-repair. Once the self-repair completed for that user, it worked and didn't trigger the self-repair any more for that user. This self-repair didn't occur for the admin users.

当我使用 Orca 检查 MSI 时，在ModuleDependency"表中，这个 tabctl32 模块具有 COMCAT msm 和 OLEAUT32 msm 的依赖关系，我们也将它们与合并模块一起安装.

When I examined the MSI with Orca, in "ModuleDependency" table, this tabctl32 module had the dependencies with COMCAT msm and OLEAUT32 msm, we installed them with the merge modules as well.

我不明白为什么管理员用户不会进行自我修复，而标准用户会进行自我修复?

I don't understand why the self-repair doesn't happen for the admin-users but for the standard users?

谁能解释一下这里发生了什么?

Can anyone explain what's going on here?

推荐答案

这可能与标准用户、管理员用户或 OCX 无关 - 它可能只是不同用户.

It may be nothing to do with standard users or admin users or OCXs - it may just be different users.

如果 MSI 中存在由特定用户拥有的任何资源(例如个人文件夹或其他文件夹中的面向用户的文件，或 HKCU 中的注册表项)，则第一次安装将安装所有这些用于安装用户.

If there is any resource in the MSI that is owned by a particular user (such as a user-oriented file in Personal folders or others, or registry entry in HKCU) then the first install will install all of these for the installing user.

如果另一个用户登录并使用该应用程序(希望每台机器安装)，那么修复触发器(例如使用快捷方式)会注意到该特定用户缺少这些用户项目，并将安装它们.这应该只发生一次 - 如果对同一用户重复进行修复，则情况会更严重.

If another user logs in and uses the app (installed per machine, hopefully) then repair triggers (such as using a shortcut) will notice that these user items are missing for this particular user and will install them. This should happen only once - it the repair happens repeatedly for the same user then it's something more serious.

在任何情况下，应用程序事件日志都应该有一个 MsiInstaller 日志条目，其中包含有关产品和缺失组件的一些数据.

In any case, the application event log should have an MsiInstaller log entry with some data about the product and the missing component.

这也可能取决于 VB6 应用程序 - 它很旧，没有清单，因此可能以奇怪的方式与 UAC 交互.例如，如果它的行为被虚拟化为使用系统文件夹的 \VirtualStore 位置，那么它可能需要将选项卡控件重新安装到该虚拟化系统文件夹中.管理员用户不会有同样的问题.

This may also depend on the VB6 app - it's old, has no manifest, and so may be interacting with UAC in strange ways. For example, if its behavior is virtualized to use a \VirtualStore location for the system folder then it may well need to reinstall the tab control into that virtualized system folder. Admin users wouldn't have the same issue.

这篇关于通过合并模块安装 Tabctl32 时为非管理员用户触发的 MSI 自我修复的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！