Почему рекомендуется ограничивать использование пользовательских действий в моих настройках WiX / MSI?

Почему рекомендуется ограничивать использование пользовательских действий в моих настройках WiX / MSI?

Развертывание является важной частью большинства разработок. Пожалуйста, дайте этому контенту шанс. Я твердо убежден в том, что качество программного обеспечения может быть значительно улучшено небольшими изменениями в дизайне приложений, чтобы сделать развертывание более логичным и более надежным - вот в чем заключается этот "ответ" - разработка программного обеспечения.

Это вопрос в стиле Q/A, отделенный от ответа, который стал слишком длинным: как избежать типичных ошибок проектирования в моем решении по развертыванию WiX / MSI?,

Источник

2 ответа

Решение

Короткая "Народная" версия:

В целом: современная установка должна быть "объявлена", а не закодирована. msgstr "думать о SQL-запросах, а не о сценариях". Применяйте хорошо проверенную логику, которую вы просто вызываете для выполнения работы. Подробнее об этом позже.

  • Избегайте пользовательских действий, если можете.
    • Они будут болтать с твоей головой (и убивать твою девичью фигуру)!
    • Серьезно: они являются основной причиной сбоя развертывания.
    • Они имеют " заговорщическую сложность ", при которой вещи часто ломаются неожиданно и без предупреждения после того, как вы развернули свою установку в течение некоторого времени, и она "в дикой природе".
    • Развертывание - это процесс - вам придется иметь дело с " прошлыми грехами " для каждого нового выпуска. Это может стать настоящим кошмаром, чтобы убрать вещи после сломанных развертываний. Каждая итерация добавляет новые потенциальные источники ошибок (мое исправление для моего неудачного исправления, сбой и т. Д.).
    • Требования времени выполнения для управляемого кода и настраиваемых действий сценариев очень подвержены ошибкам (особенно, на мой взгляд,.NET). Настройка, если она есть, должна содержать " минимальные зависимости ", поскольку она используется для прямой установки зависимостей и должна выполняться на " любой машине " в " любом состоянии " на " любом языке ".
    • Помимо использования встроенных конструкций MSI или пользовательских функций WiX, пользовательские действия часто можно избежать, внеся небольшие изменения в дизайн приложения, так что сложные пользовательские действия больше не нужны (примеры ниже).
  • Потратьте время на поиск и обзор встроенных функций и расширений MSI из WiX, Installshield, http://www.advancedinstaller.com/ (и других инструментов поставщика).
    • Эти расширения сделаны лучшими доступными экспертами по развертыванию, и в большинстве случаев были протестированы тысячами людей (миллионы и миллиарды в случае встроенных функций MSI).
    • Как можно сопоставить это с собственным проприетарным кодом? Если существующее решение достаточно хорошее - как обычно, - тогда ваш собственный код полностью добавляет риск, не принося никакой выгоды. Готовые решения даже поддерживают откат - общеизвестно пренебрегаемое и сложное в реализации свойство, которое фактически требуется при разработке.
    • Другими словами: когда вы используете существующие решения, вы заимствуете не только реализацию, но, что особенно важно, также QA, UAT и тестирование расширений при их использовании. Это может сэкономить недели работы и значительно способствовать стабильности развертывания.
    • Все, что нужно, - это потратить некоторое время на поиск и чтение того, что уже доступно, а не начинать с собственного кода. Черт, даже твой собственный менеджер может заняться поиском... В мире снов.
    • Настройка обычно не должна быть закодирована, она должна быть объявлена! (подумайте SQL). В этом и заключается суть установщика Windows: вы объявляете, что нужно установить, и последовательность обрабатывается самим механизмом установки. Преимущества результат - когда все сделано правильно.
  • Это действительно так. Продолжайте читать, если вы смеете! Здесь будут драконы в разгар серьезной разглагольствования. И самое главное: реальный опыт работы как с разработкой установок, так и с крупномасштабным развертыванием таких установок в корпоративных средах. Общие проблемы становятся понятнее - они более узнаваемы. И вы можете быть перегорели из-за проблем, за которые вы действительно должны ответить - которые вы чувствуете, что никогда не могли предвидеть (выполняя корпоративную упаковку и переупаковывая, вы получаете возможность увидеть, что может быть не так с одной упаковкой - для их преодоления могут потребоваться дни) в форму время от времени).
    • Пожалуйста, помните, и это не так плохо, как кажется: развертывание - это, как правило, технология с низким статусом, но серьезная ошибка. Ошибки действительно показывают. И кто-то ответит за это, и поддержка действительно почувствует это.
    • Отладка во время разработки трудна, но для развертывания это иногда почти невозможно, так как у вас обычно нет доступа к проблемным системам, и каждая проблемная система будет в совершенно другом состоянии.
    • Честно говоря: неспособность правильно развернуть программное обеспечение для конечных пользователей может быть почти самой дорогой ошибкой при разработке программного обеспечения - никто не может засвидетельствовать величие вашего решения - и это влияет на продажи, поддержку, маркетинг и дальнейшую разработку решения.
    • Плохое развертывание может определенно потопить продукт. К сожалению, хорошего развертывания недостаточно для сохранения продукта.

Fleshed Out Ranting Version:-)

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

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

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

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

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

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

  • Простите за "мелочи", перечисленные ниже. Во многом это может быть банальностью, но, возможно, используйте перечисленные аргументы, чтобы убедить себя избегать пользовательских действий и работать над лучшими решениями - обычно включающими более разумную последовательность запуска приложения и самоконфигурирование приложения. Поверьте нам, кодирование приложений будет более интересным, чем работа со сложными средствами установки Windows, установлением последовательности и олицетворением для пользовательских действий.
  • Нижеследующее обновлялось так много раз, что разделы немного непоследовательны или повторяются здесь и там. Будет очищен, как только позволит время.
  • Разработчики хорошо умеют кодировать, поэтому, при всем уважении, вы склонны злоупотреблять пользовательскими действиями, чтобы делать то, что лучше делать, используя встроенные функции MSI или готовые решения для расширений MSI, такие как доступные в WiX, для таких сложных вещей, как XML обновления файлов, IIS, COM +, правила брандмауэра, установка драйверов, настраиваемые разрешения для дисков и записей реестра, изменение привилегий NT и т. д. Такая поддержка также встречается в коммерческих инструментах, таких как Installshield и Advanced Installer.
  • Также возможно сделать многое из того, что сделано в настраиваемом действии как часть последовательности запуска приложения. Главный пример - инициализация пользовательских данных и копирование файла настроек в каждый профиль пользователя. Здесь есть краткое описание этой проблемы: создайте папку и файл в профиле текущего пользователя из профиля администратора.
  • Это очевидно, но очень часто пользовательские действия используются из-за незнания того, что уже доступно "из коробки" с помощью готовых решений. Это происходит со всеми нами все время, не так ли? Всегда есть какой-нибудь умный способ сделать то, что спасло бы тебя от горя? В общем, в любом случае - хотя иногда вы открываете новые пути. Не открывайте новые возможности в вашей настройке - если только вам это абсолютно не нужно! Сохраните его для своего приложения.
  • Я хочу подчеркнуть, что эти встроенные решения Windows Installer и расширения от WiX и коммерческие инструменты были написаны лучшими доступными специалистами по развертыванию. И более того, и, что еще важнее, они были использованы и протестированы тысячами, миллионами - чёрт даже миллиарды людей за встроенные функции MSI. Вы действительно думаете, что можете сделать что-то лучше? Мораль истории: выбирайте свои сражения и используйте свои отличные навыки кодирования для решения новых задач и позвольте развертыванию быть настолько глупым, насколько это возможно. Используйте то, что уже работает, и не изобретайте велосипед. В развертывании слишком много неизвестных, слишком много переменных, которыми невозможно управлять - вы имеете дело с " любой машиной " в " любом состоянии " и на " любом языке ". См. Раздел "Сложность развертывания" здесь, если вы хотите примеры - чуть ниже страницы - просто краткий дамп всех способов, которыми целевые системы могут отличаться по своему состоянию, когда ваш пакет попадает в него. Каждая переменная - это новая медвежья ловушка для пользовательского кода - от версии ОС до состояния приложения и ситуации с вредоносным ПО. Список можно продолжать и продолжать. Как говорится в связанном контенте: " Развертывание - это простая концепция со сложным сочетанием переменных, которые могут вызвать самые загадочные ошибки, в том числе любимую разработчиком: прерывистую ошибку. Как все мы знаем, серьезность таких ошибок не может быть завышенным, поскольку их часто невозможно отладить должным образом ".
  • В вашей настройке необходимо выполнить некоторые сложные действия, поскольку они требуют повышенных прав, и ваше приложение не должно запрашивать это во время работы. Это то, для чего нужна установка, расширенная конфигурация системы с повышенными правами - поэтому примите эту сложность, но используйте готовые решения! Не катите свой собственный сценарий и решения, используйте встроенные, хорошо проверенные вещи. Будет ли ваш скрипт работать правильно в Корее? Будут ли ваши пользовательские действия заблокированы основным антивирусным решением такого калибра, с которым у вас никогда не было времени для проверки сценария? Есть ли у вас время, чтобы написать собственную проверку того, установлена ​​ли на компьютере определенная необходимая среда выполнения, которая работает во всех локалях и во всех версиях ОС? Потенциал для ошибок здесь ошеломляет - и иногда невозможно проверить должным образом. У вас есть тестовые машины на арабском, китайском, корейском или японском? Может быть, вы делаете. Но есть ли у вас терминальный сервер для тестирования? Как насчет корейского терминального сервера? Вы проверяли свои настройки с рекламой MSI? Чтобы работали расширенные функции управления системой, вы должны сделать настройку максимально простой и стандартной. Потратьте несколько дней на поиск готовых решений, прежде чем писать что-то самостоятельно, я бы сказал. Помните, что с готовыми решениями вы не просто заимствуете их код, но, что самое важное, проверяете их QA, тестируете и UAT - что вы почти никогда не сможете надеяться повторить.
  • Тестирование в реальном мире - единственный критерий, который имеет значение - его нельзя заменить. Не принимай этот мир боли! Небольшое изменение в Windows, развернутое через Центр обновления Windows, и ваши пользовательские действия могут быть прерваны любым количеством способов. Выберите лучший бой, чтобы использовать свои навыки. Если вы боретесь с дизайном, то установщик Windows сопротивляется.
  • И многое происходит с развертыванием, которое делает его сложным - и не глупым, как мы этого хотим (просто скопируйте некоторые чертовы файлы), ваша задача - сделать его как можно более простым, но не более простым. Вот список задач по развертыванию, показывающих, почему ваш пакет достаточно "тупой": какова польза и реальная цель установки программы? Всегда используйте только готовые конструкции - это первая легкая победа. Все, что вам нужно сделать, это прочитать и немного поискать.

  • Наконец, я добавлю, что все настраиваемые действия должны поддерживать откат для возврата системы в исходное состояние в случае сбоя установки. В реальном мире это почти никогда не делается в специальных пользовательских действиях (по моему опыту). Поверьте мне, с этим сложно справиться - я боюсь слова "откат", поскольку сибирский хаски боится слова "ванна" после того, как я реализовал откат MSI в C++. Не самое веселое, что у меня когда-либо было, но в итоге все заработало правильно. Если вы хотите, чтобы в вашей настройке не было слишком много зависимостей, C++ - это то, что вам нужно, и, как мы все знаем, это не тривиальная задача. Готовые решения поддерживают откат из коробки - это просто выигрыш, если только их немного прочитать и найти, чтобы включить их. Сложность да, но вы находитесь на более твердой почве. И самое важное: если на японском компьютере произойдет неясная ошибка, мы сможем поработать над исправлением для сообщества, или стороннему поставщику потребуется ее устранить.

  • После всех этих "общих наблюдений", на чисто техническом уровне, настраиваемые действия в установщике Windows очень сложны с точки зрения реализации, планирования, подготовки и отката и, следовательно, должны использоваться, когда это абсолютно необходимо (часто для вещей раннего пользователя). Еще одной сложностью являются требования времени выполнения - например, зависимости от конкретных версий среды выполнения.NET, PowerShell или среды выполнения Installscript (язык сценариев Installshield - у него была зависимость времени выполнения, но теперь это в основном решено, раньше это было проблемой).

  • Ошибки, вызванные отсутствием требований времени выполнения, могут стать огромным препятствием для получения нулевой выгоды. По этой причине я использую только минимальные зависимости C++ DLL или Installscript при выполнении пользовательских действий. Бывает, что я использую VBScript или JavaScript для пользовательских действий только для чтения в последовательности пользовательского интерфейса. Они просто извлекают данные и не вносят системных изменений. Это единственные типы пользовательских действий, которые не подвержены ошибкам. Однако они должны быть настроены на выполнение без проверки кодов выхода (чтобы они не вызывали откат или прерывание в запущенной установке - часто в режиме основного обновления).
  • Кроме того: установщик Windows содержит собственный механизм выполнения сценариев, поэтому вы знаете, что ваши активные сценарии (VBScript, Javascript и т. Д.) Могут работать, если ваша целевая система фактически не работает (в нормальной системе отсутствует пропущенное время выполнения). Это в отличие от настраиваемых действий с управляемым кодом - на этом этапе целевые системы могут полностью не иметь времени выполнения.NET (январь 2018 г.). Теперь это изменится в будущем, так как.NET становится действительно встроенной и обязательной функцией в Windows (или какой-то ее минимальной версии, размещаемой самим установщиком Windows). По-прежнему возникают проблемы с ошибкой управляемого кода настраиваемого действия по странным причинам - например, из- за неправильной версии.NET, используемой для его запуска, или из-за загрузки и использования неправильной версии CLR и т. Д. У меня ограниченный опыт, но проблемы серьезные на мой взгляд. В конце концов, я думаю, что все мы напишем настраиваемые действия управляемого кода. Я все еще буду использовать C++ для сценариев распространения по всему миру.
  • Сценарии Powershell особенно опасны для пользовательских действий, поскольку они явно не работают и не могут получить доступ к объекту сеанса MSI (источник: эксперт MSI Крис Пейнтер). Powershell также требует установки.NET Framework. Я бы никогда не использовал скрипт Powershell для пользовательских действий - даже для внутреннего корпоративного развертывания. Ваш звонок. В качестве "примера", вот эксперт в этой области, который высказывает свое мнение (устаревший элемент блога, но все еще актуален, если вы спросите меня): не используйте управляемый код для написания своих пользовательских действий!
  • Я попытался написать резюме плюсов и минусов различных типов пользовательских действий. Честно говоря, я не слишком доволен этим, но вот оно: установщик Windows не работает на Win 10, но не на Win 7 с использованием WIX. Чем я не доволен? Рекомендация JavaScript с одной стороны - я использовал его редко, и хотя это лучший язык, чем VBScript - особенно для обработки ошибок - у меня было много проблем с использованием Javascript с MSI. Это может быть причиной проблемы, существующей между клавиатурой и стулом:-), но я думаю, что есть и некоторые реальные ошибки с JavaScript. Старайтесь избегать сложного использования скриптов. Для простых вещей, таких как получение свойств, они работают нормально для меня. Однако эксперты в этой области беспощадны в отношении пользовательских действий сценария: не используйте vbscript/jscript для написания своих пользовательских действий! (Аарон Стебнер), VBScript (и Jscript) Отстой MSI CustomActions (Роб Меншинг - доброжелательность WiX).
  • Позвольте мне также добавить, что сложность настраиваемых действий - " глупая, заговорщическая сложность ", а не увлекательная работа. Это кусает тебя. Gotchas. Вы обнаружите все ошибки, которые вы сделали в свое время - по мере продвижения вперед (а затем у вас есть некоторые объяснения, которые нужно сделать) - они часто не сразу становятся очевидными (проблемы внезапно возникают при обновлении, исправлении, удалении, выполнении ваших пользовательских действий). ошибочно во время восстановления, потому что это не обусловлено должным образом и стирает определенные параметры реестра, автоматическая установка не работает должным образом - она ​​оставляет установку незавершенной, потому что настраиваемое действие существует только в последовательности пользовательского интерфейса, в Windows XP есть ошибки времени выполнения, которые вы никогда не проверял свой код с пользовательскими действиями, в целевых системах есть неработающие вещи, от которых вы себя не оградили, кто-то звонит вам и говорит, что ваш пакет не работает с активным каталогом, ваш пакет не может быть объявлен, он терпит неудачу во всех корейских и японских системах самовосстановление вызывает предупреждения времени выполнения и доступ запрещен для обычных пользователей и т. д.). У вас не будет времени, чтобы исправить это должным образом, как только он ударит вас, и вам, скорее всего, придется перейти к нестандартным решениям, чтобы вырваться за пределы следующего препятствия. И нет, я не испытал все это сам. Фактически я обнаружил большинство из этих проблем при исправлении файлов MSI сторонних поставщиков для корпоративного развертывания. Вы действительно обнаруживаете много потенциальных источников ошибок, когда видите, сравниваете, просматриваете и адаптируете сотни пакетов к корпоративному стандарту для крупномасштабного развертывания. Честно говоря, есть серьезные недостатки и ошибки во всех, кроме самых простых пакетов. И, очевидно, вы увидите, что вы сделали неправильно, когда вы сделали такие настройки поставщика несколькими годами ранее. И угадайте, что возглавляет список? Чрезмерное использование пользовательских действий, когда были доступны встроенные конструкции.
  • И, вдобавок ко всему, присущая сложность развертывания с требованием работать на любом компьютере, в любом месте и в любом состоянии, создает проблему пограничных анти-шаблонов технологии MSI. Части технологии MSI, которые вызывают многократные проблемы развертывания, потому что они плохо поняты, а иногда и хрупки в реальном использовании. В этом ответе (в нижней части) приводится краткое изложение этого: как лучше использовать файлы MSI (вместе со списком очень важных корпоративных преимуществ MSI - и случайным набором общих технических проблем, наблюдаемых в реальной жизни. мировые пакеты). Особенно последняя ссылка показалась мне менее чем идеальной после того, как я ее написал. Примите это за то, что оно есть: грязный, реальный совет, больше ничего не делая для этого. Он определяет слишком много проблем, не показывая много исправлений местами.

  • Значительная часть обращений в службу поддержки программного обеспечения обычно связана с проблемами, возникающими в процессе развертывания. Как гласит история: " ... неправильная установка вашего замечательного программного обеспечения может оказаться самой дорогой ошибкой при разработке программного обеспечения. Вы никогда не можете надеяться продать программное обеспечение, которое никогда не было возможно протестировать " (от одного из связанные ответы выше). Плохое пользовательское действие очень часто стоит за такими проблемами.

  • На мой взгляд, наиболее распространенные ненужные пользовательские действия:

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

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

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

    • Предварительно необходимые настройки и установщики среды выполнения выполняются с помощью настраиваемого действия в вашем собственном MSI. Это должно быть сделано совершенно по-другому. То, что вам нужно, это загрузчик, который может запустить вашу установку и ее предварительные требования в определенной последовательности. Коммерческие инструменты развертывания, такие как http://www.advancedinstaller.com/ и Installshield, имеют функции для этого, но бесплатные фреймворки, такие как WiX, имеют поддержку через функцию Burn, а также есть бесплатные приложения с графическим интерфейсом, такие как DOTNetInstaller (не проверенный мной) с такими функциями.

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

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

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

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

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

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

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

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

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

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

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

Источник

Идея, что настраиваемые действия должны быть ограничены, проистекает из того факта, что легко написать плохо реализованное настраиваемое действие. Плохо реализованное пользовательское действие - это то, которое в случае сбоя установки не может откатить изменения, уже внесенные в систему (например, установка службы Windows).

При этом, если пользовательское действие написано так, что в нем есть дополнительное настраиваемое действие отката, то я не думаю, что это проблема.

Шаблон, которому я хотел бы следовать, заключается в том, что для каждого "настраиваемого действия", которое, я думаю, мне может понадобиться (например, FoobarCustomAction), фактически оно состоит из 3 настраиваемых действий:

  • FoobarCustomActionImmediate - это немедленное настраиваемое действие, которое подготавливает 2 полезных нагрузки:
    • Во-первых, полезная нагрузка для передачи в FoobarCustomActionDeferred, которая предписывает системе вносить изменения для внесения изменений.
    • Во-вторых, полезная нагрузка для передачи в FoobarCustomActionRollback, который диктует, как откатить систему, изменяя изменения.
  • FoobarCustomActionRollback - это настраиваемое действие отката, которое запланировано перед FoobarCustomActionDeferred в последовательности, в котором используется полезная нагрузка, предоставленная FoobarCustomActionImmediate, для отката изменений, внесенных FoobarCustomActionDeferred в случае критического сбоя.
  • FoobarCustomActionDeferred - это отложенное настраиваемое действие, которое вносит изменения в систему всей системой.

Как и многие другие технологии, я думаю, что всегда есть способ написать плохо поддерживаемый код в WiX. Возьмите пример выше, если это пользовательское действие, которое я хочу использовать во многих различных установщиках, я должен предоставить разработчикам .wxs файл, содержащий fragment это гарантирует, что все необходимые настраиваемые действия будут указаны правильно и упорядочены. Если вместо этого код WiX просто небрежно копируется и вставляется в различные инсталляторы, вероятность неправильного выполнения настраиваемого действия возрастает. Наша работа как разработчиков заключается в том, чтобы помочь потребителям нашего кода попасть в пропасть успеха, и я думаю, что WiX обеспечивает это благодаря осторожному использованию fragment а также wixlibs,

Но разработчик установщика должен заботиться о таких вещах, WiX не навязывает это!

Источник
Другие вопросы по тегам