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

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

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

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

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

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

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

Ответ 1

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

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

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

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

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