Ответ 1

Добавление этого в качестве ответа - оно слишком длинное, как комментарий, и я думаю, что это правильный ответ. Если вы прочтете этот ответ, пожалуйста, также см. Мой комментарий выше для очень хорошего отладочного файла журнала журнала MSI от Rob Mensching (создатель WiX) - и как обеспечить, чтобы все записи вошли в файл журнала, включив "flush to log" для сбоев пользовательских действий.

Ответ

Зависимость от недостающей среды выполнения, такой как Powershell, безусловно, вызовет откат. MSI имеет собственную среду выполнения для определенных script пользовательских действий (активных скриптов). Например, VBScript и JavaScript. Для надежного развертывания рекомендуется, чтобы все пользовательские действия были либо автономными минимальными значениями С++ dll или исполняемыми файлами (win32), либо (менее желательными) VBScript или JavaScript (или даже Installscript, если вы используете Installshield - см. Подробности ниже).

Худшие пользовательские действия для обеспечения надежности и надежности - это бинарные файлы .NET, требующие определенной версии платформы .NET. Это также относится к PowerShell - это не только управляемый код, но и script. Я очень заманчиво сказать, что эти технологии не должны использоваться для развертывания, но если вам нужно использовать PowerShell, вы должны как минимум добавить "проверять PowerShell" свое собственное действие в начале вашей установки и выйти изящно с помощью отображаемое (и/или зарегистрированное) сообщение об ошибке, если PowerShell недоступен.

Это конец реального ответа:-). Ниже приведены некоторые "подробные размышления", если вы делаете пакет для общего распространения (а не просто пакет для внутреннего развертывания вашей собственной компании). Если бы я был вами, я бы его прочитал, даже если вы только развертываете внутренне, пользовательские действия PowerShell могут быть проблемой развертывания калибровки.

Оба управляемых кода и скриптов являются проблематичными. PowerShell эффективно одновременно. Вот блог Роба Меншига о том, почему пользовательские действия script являются плохими. По сути: скрипты хрупкие, им не хватает языковых функций, их трудно отлаживать, а антивирусные продукты часто блокируют их. Читайте блог. И вот блог Аарона Стебнера о том, почему плохой код плохого. По сути вам не гарантируется правильная среда выполнения, когда вы зависите от наличия платформы .NET.

Подробные размышления

Я не уверен, что установлено как стандарт для Win7 и Win10. Если вы развертываете как "внутренний пакет" для своей компании, я думаю, что должно быть достаточно просто добавить надежную проверку наличия PowerShell, а затем прервать значимое сообщение об ошибке, если PowerShell не найден. Но общие исполняемые файлы .NET и скрипты PowerShell являются наихудшими пользовательскими действиями для надежности. Я бы никогда не использовал их для настройки таргетинга на разные компьютеры.

Если вы делаете MSI для общего распространения на любом компьютере в любом месте, я бы потратил время, чтобы преобразовать PowerShell script в нечто другое. Предпочтительно С++ dll, который я считаю наиболее надежным. Зависимости от слов или слоев не зависят. Даже InstallScript допустим, если бы вы использовали Installshield (он может работать без предустановленной среды выполнения на этом этапе, что значительно улучшило его надежность и полезность), это тупой язык, хотя и с довольно архаичным синтаксисом. Справедливости ради не следует недооценивать - он выполняет эту работу и проще, чем С++).

JavaScript и VBScript пользовательские действия возможны для использования даже для MSI, которые предназначены для общего распространения на любом компьютере, но не рекомендуется. Я использую их только для пакетов "внутреннего развертывания компании". Они могут быть стандартизированы, а критические сценарии прозрачны для других системных администраторов и упаковщиков. Они могут видеть и проверять, что делается в рамках установки. Обычно это желательно и одно из ключевых преимуществ MSI для корпоративного развертывания, но иногда вам требуется скомпилированный двоичный код для скрывать детали реализации(например, при проверке лицензионного ключа). Тогда скрипты любого типа не могут быть использованы - очевидно. Будучи прозрачным, а также встроенным в MSI (поэтому всегда доступен полный, работающий источник), он помогает различным упаковщикам приложений собирать кого-то другого, когда это необходимо. И в команде развертывания всегда есть кто-то, доступный для отладки скриптов - но мало кто может знать правильный С++. В корпорациях, где разработчики внутренних приложений создают свои собственные файлы MSI без значительных знаний о развертывании, сценарии могут полностью сбиться с пути и вызывать очень сложные проблемы с развертыванием. Очень часто требуется небольшое изменение самого приложения, чтобы обеспечить более надежное развертывание. Например, приложение должно выполнить собственную конфигурацию запуска - ни одно из этих действий не должно выполняться в сценариях установки, но многие разработчики делают это.

Использование script настраиваемых действий противоречиво. Если вы спросите двух экспертов по развитию, вы получите 4 мнения. На мой взгляд, пользовательские действия (сценарии) "белого ящика" хороши для корпоративного использования, если они делают что-то конкретное, что не является общим, поэтому люди могут видеть, что происходит. Для вещей, которые необходимы все время, корпорация должна создавать скомпилированную С++ dll, управляемую пользовательскими таблицами в файле MSI, с полной поддержкой QA и откатом - то, что обычно отсутствует для всех script пользовательских действий (это не тривиально для реализации). "Собственные данные" (пользовательские таблицы). Пользовательское действие С++ имеет минимальные зависимости как самую большую силу, а также прозрачно (что будет прозрачно, но фактическая реализация скомпилирована и скрыта, что также может повысить безопасность). Набор инструментов WiX предоставляет такую ​​настраиваемую DLL с поддержкой отката, написанную на С++. Он должен решить большинство пользовательских задач, необходимых для развертывания корпораций. Все это выходит за рамки вашего вопроса - просто отступление: -).

Если бы я догадался, я бы сказал, что установщик Windows может быть обновлен, чтобы иметь возможность размещать собственную среду выполнения для Powershell - но это всего лишь предположение. Я не уверен в технических деталях - казалось бы, потребуется вся среда исполнения .NET? Если вы спросите меня, я бы все же предпочел JavaScript для PowerShell script, но я понимаю, что вы, вероятно, привержены PowerShell как стандарт компании? Кроме того, всегда предпочитает JavaScript над VB script, поскольку он имеет что-то похожее на обработку исключений (чего не хватает VB script).

Роб Меншинг, Крис Пейнтер, Фил Уилсон, Боб Арнсон и, возможно, другие (я не уверен в позиция Стефана Крюгера в сценариях или вид Роберта Дикау) - убьет я для этого, но вот шаблон для пользовательского действия JavaScript (непроверенный мной, но выглядит нормально): Как отлаживать пользовательское действие MSI, которое реализовано в Javascript?. Если я могу просто выговорить: в настоящее время все лучше PowerShell - даже JavaScript.

Будьте уверены, я потратил много времени на отладку очень плохих VB script пользовательских действий. Вероятно, самый некомпетентный и лишенный язык, когда-либо используемый для развертывания. On Error Resume Next для обработки ошибок? Это не может стать намного хуже. Обычно я использую только сценарии для операций только для чтения и устанавливаю действия свойств.

Возможно, мы увидим устаревшие версии VB script и PowerShell в свое время добавили в качестве жизнеспособной опции сценариев MSI? Я бы не стал считать это безопасным до тех пор, пока все используемые операционные системы не будут иметь хотя бы базовую версию установленной платформы .NET, и даже тогда я считаю, что политики могут блокировать использование определенных версий .NET. Вы хотите, чтобы пакет, который неожиданно не удалось удалить, поскольку целевая версия .NET Framework больше не работает? Устранение такой проблемы может быть невероятным объемом работы - особенно для корпорации с большой пакет.

Рекомендуемая реализация специальных действий

Я написал сводку "рекомендаций" для реализации пользовательских действий. Он стал длинными страницами, не сказав многого - я удалил его. Вместо этого, вот список моих предпочтений реализации пользовательских действий (в порядке уменьшения надежности и надежности):

• С++ dll
• Installscript (только InstallShield)
• JavaScript
• VB script
• С# DTF
• PowerShell

Резюме:

• Для меня PowerShell на момент написания абсолютно худшего выбора. Это и управляемый код (ненадежное время выполнения) и a script пользовательское действие (плохая отладка).
• Я хотел бы написать специальные действия С#/DTF, например, Chris для простоты, но я не верю, что время созрело - среда выполнения не может быть гарантирована. В реальном мире вы не выбрасываете рабочую С++ dll в пользу С# dll. Это огромное снижение надежности.
• С++ dll и Installscript - это единственный выбор для настройки профессионала, настройки поставщика таргетинга на различные компьютеры (не стандартизированные рабочие столы в управляемых средах - корпораций, но компьютеров в любой точке мира во всех их гетерогенных состояниях, на разных языках и различных конфигурациях аппаратного и программного обеспечения).
• С++ custom action dll значительно сложнее настраивать и настраивать, чем другие пользовательские действия с его экспортом, строить настройки и выходы, но это не волшебная невозможность. В ответ вы получаете много: полная отладка, расширенные функции языка и обработка ошибок. И большой: минимальные зависимости (убедитесь, что вы включили статическое связывание для устранения всех возможных зависимостей). Для отладки вы можете просто подключить отладчик Visual Studio к окну сообщения, отображаемому вашим пользовательским действием, а затем вы можете выполнить код. Это работает как для пользовательских, так и для пользовательских действий. Полный контроль. Это фактически делает отладку настраиваемого действия С++ проще, чем пользовательское действие script, и, безусловно, более надежное.
• VB script Я бы никогда больше ничего не использовал. Отсутствие обработки ошибок делает его очень ненадежным. Это просто не полный язык. Я все еще думаю, что он более надежный, чем управляемый код.
• JavaScript подходит для внутреннего корпоративного использования "в управляемой среде. Я бы никогда не использовал его для настройки поставщика для общего распространения. Но для распространения пакетов в корпоративной сети он может быть использован. Как для разработчиков, так и для собственных приложений, а также для приложений, настраивающих сторонние настройки для корпоративного развертывания. Основные преимущества и недостатки действий JavaScript:
  • Как указано выше, скрипты должны использоваться только в редких случаях, и для всех обычных задач сценариев, которые люди склонны повторно использовать, следует использовать dll win32 С++ dll или WiX. Сценарии должны использоваться только тогда, когда это необходимо для выполнения заданий.
  • Пользовательские действия JavaScript, как и все script пользовательские действия, обычно трудно отлаживать, уязвимы для антивирусных помех и , лишенных языковых возможностей, необходимых для реализации усовершенствованных конструкций кодирования. У вас просто нет функций языка и гибкости, доступных с С++
  • Скрипты прозрачны для всех (как для цели, так и для реализации), и их можно легко отлаживать и поддерживать несколькими членами команды с работой, переданной между ними. Все могут видеть, что происходит, и каждый может быстро заставить кого-то работать.
  • Источник, встроенный в MSI , является правильным источником, вам не нужно поддерживать исходные файлы отдельно в репозитории для его компиляции, как вам нужно для управляемого кода (С#). Для управления упаковкой исходного кода редко устанавливается мой опыт (это должно быть, хотя).
  • Корпоративные пакеты нацелены на стандартную рабочую среду (SOE). Все рабочие станции похожи или одинаковы, с тем же антивирусным решением. Это, очевидно, означает, что целевые компьютеры находятся в гораздо более однородном состоянии, чем обычные. Любые проблемы с антивирусом будут обнаружены и могут быть обработаны. Лично я не видел серьезных проблем с антивирусными помехами с простыми сценариями для такого развертывания пакетов.
  • В script есть много опыта в отладке в командах упаковки, но очень мало знаний на С++ (многие знают некоторые С# и PowerShell). Разработчики, скорее всего, предпочтут С#, но могут легко обрабатывать JavaScript.

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