Я сделал это. В качестве значения реестра использовалось приложение, связанное с расширением файла, но это может быть любое значение реестра.
Моей первой идеей было использовать «настраиваемые действия» для установки и удаления для сохранения
и восстановить, соответственно, связанное состояние regy. это
казалось достаточно простым.
Я создал проект установки в VS2008 и создал CA как файлы javascript. Сценарий «при установке» захватил существующее значение regy и спрятал его в известном месте. Сценарий «при удалении» будет искать в известном месте, а затем помещать найденное значение обратно в исходное местоположение.
Легко, правда?
Было две проблемы:
скрипт, который запускался во время установки, чтобы сохранить существующее значение реестра,
работает ПОСЛЕ реестра уже обновлен
со значениями для вновь установленной вещи. Таким образом, он сохранил новую настройку вместо настройки, существовавшей до запуска MSI. Не полезно.
Сценарий, который запускается во время удаления, запускается ПОСЛЕ значений реестра и фактически всего поддерева каталога,
были удалены Включая скрытое значение. Так что он потерял свое состояние.
Для решения этой проблемы я написал другой скрипт, который
измените порядок пользовательских действий , чтобы они выполнялись в нужное время.
На самом деле есть еще один поворот. Очевидно, сценарий «Восстановить» (на
удалить) не будет работать, если он будет запущен после удаления записей реестра для приложения. Теперь я не могу вспомнить, почему ... но я также определил, что этот сценарий не может запускаться до этого . Почему-то это тоже не сработало.
Итак, я изменил MSI для запуска сценария восстановления
дважды . На этапе 1 он передает спрятанное значение в «парковку» в реестре.
Затем ключи и значения приложения в реестре удаляются, но парковка остается. В
Фаза 2, за пределами защиты транзакций, сценарий восстановления получает состояние с парковки, восстанавливает
файл ассоциации, а затем удаляет парковку.
Я не могу точно вспомнить, почему мне нужно было сделать это в 2 этапа, но я помню, как боролся с этим некоторое время, прежде чем придумал это решение.
Как это работает в разработке:
- установить
on install и on uninstall CA в проекте VS
- сборка проекта установки VS
- запустить скрипт постобработки, который изменяет MSI.
При использовании MSI это немного сложнее, чем я думал, но работает.
Если вы используете WiX, вы можете лучше контролировать время и порядок шагов, поэтому вам может не понадобиться этот шаг постобработки.
Наконец, вы сказали, что хотите избежать CA. Для меня, CA избегают, потому что их больно производить в C ++, а создавать их в .NET часто неуместно. Но довольно просто использовать Javascript для CA. Некоторые люди думают, что скрипт - это неправильный инструмент для работы CA . Я думаю, что это неправильно. Я думаю, что скрипт - очень хороший инструмент для этой цели . И как только вы сможете принять скрипт в качестве хорошего инструмента, вам не нужно будет думать о создании собственного CA.