Установщик Windows не работает на Win 10, но не на Win 7 с использованием WIX

Мне недавно было поручено обновить установщик наших проектов для работы в Windows 10, и я немного растерялся, как заставить его работать. У меня нет опыта работы с установщиками, и я нахожусь в процессе ознакомления не только с процессом в целом, но и с тем, как наш проект справляется с ним.

На данный момент программа установки отлично работает на нашей виртуальной машине с Windows 7, но при запуске на нашей виртуальной машине с Windows 10 происходит сбой в конце и начинается откат. Я получил его, чтобы выплевывать некоторые файлы журналов, и я копаюсь в них, но я довольно потерян.

Я отследил этот бит:

MSI (s) (B0:F4) [17:39:02:883]: Note: 1: 1708 
MSI (s) (B0:F4) [17:39:02:883]: Note: 1: 2205 2:  3: Error 
MSI (s) (B0:F4) [17:39:02:883]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1708 
MSI (s) (B0:F4) [17:39:02:883]: Note: 1: 2205 2:  3: Error 
MSI (s) (B0:F4) [17:39:02:883]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 
MSI (s) (B0:F4) [17:39:02:883]: Product: GPEP -- Installation failed.

Ближе к концу, который, кажется, происходит в момент или около того, когда установщик, кажется, отказывает.

Следующая строка имеет это в конце:

Installation success or error status: 1603.

Я посмотрел на ошибку и нашел это: Ошибка 1603

Я ищу решения на этой странице, но все это должно быть в порядке. Мы запускаем установщик таким же образом с теми же разрешениями на виртуальных машинах Win 10 и Win 7.

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

Источник

1 ответ

Решение

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

Ответ

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

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

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

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

Verbose Musings

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

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

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

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

Если бы я догадался, я бы сказал, что установщик Windows может быть обновлен, чтобы можно было размещать собственную среду выполнения для Powershell - но это всего лишь предположение. Я не уверен в технических деталях - может показаться, что понадобится вся среда выполнения.NET? Если вы спросите меня, я все же предпочел бы Ja vaScript сценарию PowerShell, но я понимаю, что вы, вероятно, привержены PowerShell как стандарту компании? Также, всегда предпочитаю Ja vaScript над VB Script поскольку в нем есть что-то похожее на обработку исключений (чего в VB Script нет совсем). ОБНОВЛЕНИЕ: реальное тестирование показывает, что VBScript лучше использовать с MSI, чем с Javascript. Например: я видел неясные проблемы при доступе к MSI API с помощью Javascript. Сам MSI, вероятно, был протестирован больше с VBScript, чем с Javascript, когда он был создан. Давайте будем честными: оба "языка" имеют серьезные ограничения, и оба трудно отладить.

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

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

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

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

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

ОБНОВЛЕНИЕ Май 2018: больше не рекомендуется Javascript поверх VBScript.

  1. C++ dll
  2. Installscript (только InstallShield)
  3. VB Script
  4. Ja vaScript
  5. C# DTF
  6. PowerShell

Резюме:

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

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

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