Постоянство данных для установки MSI
Установка MSI вызовет мои (собственные / C ++) функции пользовательских действий. Поскольку библиотека DLL недавно загружена, и процесс MSIEXEC.EXE запускается отдельно для каждой функции (вызываемые действия, как указано в скрипте MSI / WiX), я не могу использовать какие-либо глобальные данные в программе C / C ++.
Как (или Где) я могу хранить некоторую информацию о продолжающейся установке?
Я не могу использовать именованные объекты (например, разделяемую память), так как «процесс», который запускает DLL для вызова функции «action», завершится, и ОС не сохранит именованный объект.
Я могу использовать внешний файл для хранения, но тогда как я узнаю (в функции DLL):
- Когда удалять внешний файл.
- Когда обнаруживается, что этот вызов функции является первым вызовом (вызов действия / функции
Before="LaunchConditions"может помочь, не очень уверен).
Если я не могу удалить файл, я не могу знать, является ли «информация» текущей или устаревшей (то есть принадлежащей к предыдущей неудачной / успешной работе MSI).
«Временные таблицы MSI» я слышал, но не уверен, как их использовать.
Решение
Сохранить настройки: Я немного запутался в том, что делают ваши обычные действия, если честно. Тем не менее, похоже, что они сохраняют настройки из более старого приложения и версии установки и возвращают их на место, если 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 может быть лучше.
Другие решения
Других решений пока нет …