Самостоятельный ремонт MSI для пользователя, не являющегося администратором, когда Tabctl32 был установлен с помощью модуля слияния

Question

Одним из наших приложений является приложение VB6, для которого требуется Tabctl32.ocx.

Так что я добавил «tabctl32.msm» (который содержал его с версией 6.1.97.82) для Wix на основе машин. Когда я запускал этот MSI для каждой машины, он установил, что OCX и приложение отлично работали, когда я был зарегистрирован как администратор и запустил приложение VB.

Однако, если кто-либо со стандартными правами пользователя зарегистрировался и впервые запустил это приложение VB, он вызвал саморемонт MSI. Как только саморемонт завершен для этого пользователя, он работал и больше не запускал саморемонт для этого пользователя. Этот саморемонт не произошел для пользователей admin.

Когда я изучил MSI с Orca, в таблице «ModuleDependency», этот модуль tabctl32 имел зависимости с COMCAT msm и OLEAUT32 msm, мы также установили их вместе с модулями слияния.

Я не понимаю, почему саморемонт не происходит для пользователей-администраторов, а для стандартных пользователей?

Может ли кто-нибудь объяснить, что здесь происходит?

Answer 1

Это может быть не что-то общее со стандартными пользователями или пользователями администраторов или OCX - это может быть только разных пользователей.

Если в MSI есть какой-либо ресурс, принадлежащий определенному пользователю (например, ориентированный на пользователя файл в личных папках или других местах или запись реестра в HKCU), то первая установка будет устанавливать их все для установка пользователь.

Если другой пользователь входит в систему и использует приложение (установленное на машину, надеюсь), то восстановление триггеров (например, использование ярлыка) заметит, что эти пользовательские элементы отсутствуют для этого конкретного пользователя и будут их устанавливать. Это должно произойти только один раз - это ремонт повторяется для одного и того же пользователя, тогда это нечто более серьезное.

В любом случае журнал событий приложения должен иметь запись журнала MsiInstaller с некоторыми данными о продукте и отсутствующем компоненте.

Это также может зависеть от приложения VB6 - оно устарело, не имеет манифеста и поэтому может взаимодействовать с UAC странным образом. Например, если его поведение виртуализировано для использования местоположения \ VirtualStore для системной папки, возможно, потребуется переустановить элемент управления вкладкой в ​​эту виртуализованную системную папку. У пользователей Admin не было бы такой же проблемы.