Лучший способ обмена данными между всеми настраиваемыми действиями Установите Shield

1

Мы используем пользовательские действия в Install Shield с С#, и я хочу поделиться данными между несколькими пользовательскими действиями.

У меня уже есть подход к написанию его в текстовый файл из первого пользовательского действия, а для остальных пользовательских действий - чтение значения из этого файла.. но я не считаю его хорошим подходом по следующим причинам.

  1. Операции ввода-вывода являются дорогостоящими, и их необходимо выполнить для всех пользовательских действий.
  2. Письменный файл может быть проблемой разрешения для определенных операционных систем, так как установщик будет выполняться на нескольких операционных системах Windows, так что любая несоответствие создаст проблему в Installer.

Итак, я ищу лучшее решение, которое может справиться с этим сценарием.

С нетерпением ждем отличных ответов..

Теги:
installshield

2 ответа

0

Из того, что я могу сказать, теория состоит в том, что немедленные действия могут точно определить, какие последующие действия, связанные с ней, должны будут знать, и, таким образом, могут задавать свойства или CustomActionData для последующих действий по мере необходимости. Свойства могут хранить любой формат сериализации, который вы можете представить в строке с нулевым завершением. Это действительно поддерживаемый механизм установщика Windows для обмена мгновенными действиями, и в особенности с отложенным действием.

Однако на практике это не всегда правильно. Иногда чтение текущего состояния машины требует административных привилегий, недоступных для немедленного действия. Иногда, чтобы выполнить эффективный откат или совершить действие, вам нужно знать, что произошло во время повышенной попытки внести изменения. Даже когда сбор информации возможен без повышенных привилегий, это может быть трудно спланировать все это раньше времени, и это соблазняет компромисс между легкостью и теоретической корректностью.

Необязательно вместо этого передавать имя файла через механизм свойств и обновлять общий файл по мере его описания. Основное различие заключается в том, что имя файла не задано; он хранится в% TEMP% или аналогично, и его имя передается через свойства. Это решает вопрос о возвышении, но не обязательно вопрос безопасности.

0

Мы используем 2 способа сделать это
- Если нам нужны общие текстовые данные и только во время одного процесса установки - мы используем общие свойства. Первый CA устанавливает свойства, другие считывают эти данные. MsiSetProperty и MsiGetProperty помогут вам здесь, но не забывайте о доступе или настройке свойств установщика Windows с помощью отложенных, коммандных и откатных пользовательских действий.
- При необходимости обмениваться данными между различными процессами установки - мы используем Registry и System Search. Первый установщик записывает данные в какое-то место в реестре - другие читают его с помощью поиска системы и устанавливают соответствующие свойства.

  • 0
    Игорь, нам нужно получить доступ к этому свойству с помощью пользовательских действий в c #, чтобы мы могли обрабатывать его в c #, с помощью MSiSetProperty и MsiGetProperty, я думаю, нам нужно отправлять его через каждое настраиваемое действие в качестве параметра, верно? Есть ли лучший подход, я думаю, что реестр и системный поиск также зависят от привилегий компьютера. Вы можете предложить что-то еще?
  • 0
    1. Свойства, которые вы установили в первом ЦС, будут доступны для чтения из следующих. Не уверен, понимаю ли я, зачем вам отправлять их (свойства другим ЦС), если они хранятся в памяти, и вы можете прочитать эти свойства в любой момент после их установки. 2. Второй способ хорош только для отправки данных другим установщикам (если их несколько, например в цепочке MSI)

Ещё вопросы

Сообщество Overcoder
Наверх
Меню