Постоянство данных для установки MSI
Установка MSI вызовет мои (собственные /C++) функции пользовательских действий. Поскольку библиотека DLL недавно загружена, и процесс MSIEXEC.EXE запускается отдельно для каждой функции (вызываемые действия, как указано в скрипте MSI/WiX), я не могу использовать какие-либо глобальные данные в программе C/C++.
Как (или Где) я могу хранить некоторую информацию о продолжающейся установке? Я не могу использовать именованные объекты (например, совместно используемую память), поскольку "процесс", который запускает DLL для вызова функции "action", завершится, и ОС не сохранит именованный объект.
Я могу использовать внешний файл для хранения, но тогда как я узнаю (в функции DLL):
- Когда удалять внешний файл.
- Когда обнаруживается, что этот вызов функции является первым вызовом (вызов действия / функции
Before="LaunchConditions"может помочь, не очень уверен).
Если я не могу удалить файл, я не могу знать, является ли "информация" текущей или устаревшей (то есть принадлежащая ранее неудачному / успешному запуску MSI).
"Временные таблицы MSI" я слышал, но не уверен, как их использовать.
1 ответ
Сохранить настройки: если честно, я немного запутался в том, что делают ваши пользовательские действия. Тем не менее, похоже, что они сохраняют настройки из более старого приложения и версии установки и возвращают их на место, если MSI не удается правильно установить?
Предложение по миграции (пожалуйста, серьезно рассмотрите этот вариант): не могли бы вы установить новый пакет MSI и удалить все ярлыки и доступ к старому приложению, оставив его вместо этого установленным? Ваша новая версия приложения устанавливается по новому пути и в новый куст реестра, а затем вы переносите все настройки при первом запуске нового приложения, а затем запускаете удаление старого приложения - каким-либо образом - или просто оставляете его установленным, если это приемлемо.? Есть ли COM-серверы в вашей старой установке? Другие вещи, которые имеют глобальную регистрацию?
Воздержание от пользовательских действий: Выше приведено лишь предложение избегать пользовательских действий. Есть много причин, чтобы избежать пользовательских действий (пропаганда против пользовательских действий). Если вы переносите настройки при запуске приложения, вы избегаете всех sequencing, conditioning, impersonation проблемы наряду с technical issues вы уже сталкивались (есть еще много) с использованием пользовательских действий. И главное, вы в знакомом debugging context (код запуска приложения), в отличие от незнакомого мира настроек и их плохой отладки.
Сохранение настроек и данных. Что касается сохранения данных и настроек в работающем экземпляре MSI, встроенный механизм в основном устанавливает свойства с помощью Session.Property (COM / VBScript) или же MsiSetProperty (Win32) звонки. Это позволяет сохранить строки внутри MSI Session объект. Сортировка глобальных данных.
Обратите внимание, что свойства могут быть установлены только в непосредственном режиме (настраиваемые действия, которые не изменяют систему), и отправка данных в настраиваемые действия отложенного режима (которые могут вносить изменения в систему) довольно сложна, сосредоточившись вокруг CustomActionData концепция ( подробнее об отложенном режиме и CustomActionData).
По сути, вы отправляете строку в пользовательское действие отложенного режима с помощью пользовательского действия SetProperty в непосредственном режиме. Как правило, это строка, разделенная по домам, которую вы создаете в непосредственном режиме и разбиваете на информационные фрагменты при получении в отложенном режиме. Вы можете попробовать использовать JSON-строки и тому подобное, чтобы сделать передачу более простой и надежной, выполняя сериализацию и десериализацию объектов через строки JSON.
Альтернативы?: Этот подход с использованием набора свойств задействован. Некоторые люди пишут в и из реестра во время установки или во временный файл (во временной папке), а затем очищают во время фазы фиксации MSI, но мне не нравится этот подход по нескольким причинам. С одной стороны, принятие пользовательских действий может не выполняться на основе политик на целевых системах ( когда откат отключен, сценарий принятия не создается - см. Раздел " Выполнение выполнения "), и это не лучший метод. Добавление временных строк - интересный вариант, на который я никогда не тратил много времени. Я сомневаюсь, что вы могли бы легко использовать это для достижения того, что вам нужно, хотя я не знаю, что вам нужно в деталях. Я не использовал это должным образом. Быстрый образец. Этот пример RemoveFile из WiX может быть лучше.