Ответ 1

Как указано выше , этот раздел был разделен на существующий ответ с более широкой областью: Как избежать общих недостатков дизайна в моем WiX/MSI решение для развертывания? (ответ, призванный помочь разработчикам лучше принимать решения о развертывании).

6. Ошибочное или ненужное использование пользовательских действий.

Множество проблем с развертыванием может быть вызвано использованием пользовательских действий - большинство из них очень серьезны. Если ваша установка не завершилась или завершится с ошибкой, это справедливая ставка, что ошибочное пользовательское действие виновато.

Соответственно очевидным решением является ограничение использования пользовательских действий по мере возможности. Пользовательские действия " черный ящик" (скрытый код), тогда как большинство MSI обладает большой прозрачностью. Формат MSI можно легко просмотреть, и все, что делает файл MSI, по существу может быть выведено из файла базы данных MSI - за исключением скомпилированных пользовательских действий.

6.1. Чрезмерное использование пользовательских действий

• Разработчики хорошо разбираются в кодировании - поэтому они склонны злоупотреблять пользовательскими действиями, чтобы делать то, что лучше делать, используя встроенные функции MSI или готовые решения для расширения MSI, такие как доступные в WiX для расширенных функций, таких как обновления XML файлов, IIS, COM +, правила брандмауэра, установка драйвера, пользовательские разрешения для записей диска и реестра, изменить привилегии NT и т.д.... Такая поддержка также обнаруживается в коммерческих инструментах, таких как Installshield и Advanced Installer.

• Пользовательские действия в установщике Windows очень сложны в отношении реализации, планирования и отката и должны использоваться, когда это абсолютно необходимо. Наиболее распространенные ненужные пользовательские действия, которые мы видим, на мой взгляд:

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

  • Вы устанавливаете сборки .NET в GAC посредством настраиваемого действия. Это полностью поддерживается установщиком Windows без строки (рискованного) кода.

  • Вы запускаете пользовательские классы установщика сборки .NET. Они должны использоваться для разработки и тестирования только. Они должны никогда выполняться как часть развертывания. Скорее ваш MSI должен использовать встроенные конструкции для развертывания и регистрации вашей сборки.

  • Вы запускаете предварительные установки и установщики времени выполнения с помощью настраиваемого действия в вашей собственной MSI. Это нужно делать совершенно по-другому. Вам нужен загрузочный блок, который может запускать вашу установку и ее предварительные условия в последовательности. Инструменты коммерческого развертывания, такие как Advanced Installer и Installshield есть функции для этого, но бесплатные фреймворки, такие как WiX имеет поддержку через функцию записи, а также есть бесплатные графические приложения, такие как DOTNetInstaller (непроверенный мной) с такими функциями.

  • Послушайте меня в этом конкретном случае: запуск встроенных настроек с помощью настраиваемого действия в конечном итоге не удастся - обычно довольно быстро. MSI слишком сложна в своем планировании, олицетворении, транзакции, откате и общей архитектуре времени выполнения, чтобы сделать это возможным. Только одна транзакция MSI может выполняться одновременно по дизайну, и это делает вещи очень сложными. Раньше вы могли запускать встроенные MSI файлы в качестве концепции в MSI, но это было устаревшим - это не сработало. Вы должны запускать каждую установку последовательно. Правильная последовательность.

6.2 Пользовательские альтернативы действий

• Готовые решения, найденные в WiX и других инструментах, таких как Installshield и Advanced Installer, проверены и протестированы и, в сущности, также обеспечивают надлежащую поддержку отката - почти всегда отсутствующую функцию реализация пользовательских действий - даже в других хороших настройках MSI поставщика. Откат - очень важная функция MSI. Вы не можете конкурировать с качеством, поставляемым из большого сообщества пользователей, с активным использованием и тестированием во всех видах среды. Используйте эти функции.

• Помимо использования встроенных конструкций MSI или пользовательских функций WiX, часто можно избежать пользовательских действий путем незначительных изменений в дизайне приложения, чтобы более сложные пользовательские действия больше не нужны. Я вижу лицензирование в качестве примера того, как развертывание можно упростить для повышения надежности.

  • Это очень важный момент, и это очень часто игнорируется. Иногда некоторые качественные часы или дни кодирования и некоторое время UAT/QA качества могут предотвратить долговременные проблемы развертывания из когда-либо существующих. Никакое количество времени поддержки не может решить худшие проблемы с развертыванием, которые вы можете создать.

  • В этом ответе приведен фрагмент общей сложности развертывания: установщик Windows и создание WiX (в сторону нижней). Развертывание - сложный "процесс доставки" с несколькими серьезными проблемами: 1) кумулятивный характер ошибок развертывания, 2) трудность правильной отладки и 3) практически неограниченный диапазон внешних факторов и переменных, влияющих на целевые машины по всему миру. - вывод заключается в том, что развертывание должно быть максимально простым, чтобы быть надежным. Есть так много промежуточных факторов, которые оставляют вас с любимым разработчиком: прерывистая ошибка. Ссылка, приведенная выше, рекомендуется для более подробного объяснения.

6.3 Усовершенствованные пользовательские действия (за пределами ошибок выполнения)

• Очень распространенная проблема с настраиваемыми действиями - это их неправильное планирование и попытка изменить систему из "немедленных" действий немедленного режима. Это усовершенствованные недостатки дизайна MSI, которые не сразу распознаются для людей, которые видят другую рабочую настройку.

• Никогда не вставляйте пользовательские действия немедленного режима после InstallFinalize в InstallExecuteSequence вашего MSI, пытающегося изменить систему (чтение/запись). Эти действия никогда не будут выполняться, если ваша установка будет развернута в бесшумном режиме через системы развертывания, такие как SCCM (опять же, в прошлый раз, когда я проверил).

• Никогда не пытайтесь изменить систему, используя пользовательские действия немедленного режима, активированные из GUI установки. Это будет работать для пользователей admin, но пользовательские действия немедленного режима не будут повышены, и, следовательно, обычные пользователи не смогут запускать их без ошибок. Кроме того, любые изменения в системе, выполненные из графического интерфейса MSI, никогда не будут выполняться, когда установка выполняется в бесшумном режиме (тогда вся последовательность GUI пропускается). Это очень серьезный недостаток дизайна MSI: установка беззвучно и интерактивно вызывает разные результаты. Эта проблема упоминается также в разделе 10 о бесшумной установке: Как избежать общих недостатков разработки в решении по развертыванию WiX/MSI? strong > . Тихая установка - важная функция для корпоративного развертывания вашего программного обеспечения. В корпорациях, контролирующих их развертывание, ВСЕ развертывание выполняется молча. Ваш графический интерфейс установки просто никогда не видел. Есть только несколько исключений, о которых я могу думать, например о некоторых развертываниях на сервере, которые могут выполняться в интерактивном режиме, но все настольные и клиентские программы развертываются молча. Не поддерживать тихую установку должным образом, следовательно, ужасный недостаток и недостаток дизайна вашего файла MSI. Пожалуйста, прислушайтесь к этому совету.

• Все пользовательские действия, которые вносят изменения в систему, должны быть вставлены в "транзакционную секцию" последовательности установки. Эта транзакция Windows Installer Transaction (транзакция с транзакцией в базе данных) выполняется между стандартными действиями InstallInitialize и InstallFinalize в InstallExecuteSequence и работает с повышенными правами. Все изменения в системе должны произойти в этой транзакции - все остальное ошибочно (но, к сожалению, довольно часто). Все введенные здесь пользовательские действия должны также иметь соответствующее настраиваемое действие отката, и это должно отменить любые изменения, внесенные в систему в случае сбоя установки и откат.