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