Установщик Windows и создание WiX
В настоящее время мы используем WiX для создания наших MSI-файлов, и, таким образом, это единственный MSI-конструктор, который я имел опыт использования. Я знаю, что вы можете создавать инсталляторы изначально в Visual Studio. Каковы различия между использованием WiX и Windows Installer, и каковы плюсы и минусы каждого?
2 ответа
Я просто хочу добавить более конкретную техническую информацию о самой технологии Windows Installer, а также немного истории, приведшей к созданию инструментария WiX, поскольку этот пост может быть найден людьми, которые только начинают заниматься установщиками, WiX и установщик Windows.
Это задумано как краткое введение в WiX и MSI с точки зрения разработчика. Существует также несколько популярная статья на serverfault.com, которая может быть полезна для понимания преимуществ установщика Windows: корпоративные преимущества использования файлов MSI (многим разработчикам не нравится установщик Windows, но преимущества корпоративного развертывания на самом деле весьма значительны - возможно, стоит их быстро просмотреть, если вы думаете MSI больше проблем, чем оно того стоит).
Происхождение инструментария WiX
MSI -файлы, по сути, удаляются из баз данных SQL Server, хранящихся в виде COM-структурированных файлов хранения. Это формат файла, используемый в Microsoft Office (обратите внимание, что MS Office раньше использовал файлы OLE / COM - но более новые версии теперь используют Office Open XML), и он был разработан как способ хранения иерархических данных в одном файле. По сути, файловая система в файле с потоками хранения различных типов, одним из которых являются файлы для установки внутри одного или нескольких файлов cab.
Ранее MSI файлы / базы данных лучше всего изменять напрямую, используя сторонние инструменты, такие как InstallShield, http://www.advancedinstaller.com/ и Wise Package Studio (больше не доступен из-за юридических проблем - см. сравнение доступных в настоящее время инструментов MSI). Эти инструменты сохранили файл MSI в его собственном "устанавливаемом" формате как файл структурированного хранилища COM. Это означало, что ваш MSI -файл был как исходным, так и исполняемым - и в двоичном формате. Это затрудняло исходный контроль вашего проекта установки. Двоичные различия в разных базах данных MSI были сложными, и из-за ссылочной целостности базы данных даже самые базовые изменения в MSI будут касаться десятков таблиц и затруднят просмотр того, что изменилось даже для тренированных глаз.
Для разработчиков WiX стал способом создания двоичного MSI -файла из обычных текстовых исходных файлов. Как и обычный двоичный файл EXE, двоичный файл MSI "компилируется" из текстовых XML-файлов WiX. Это качественный скачок с точки зрения управления процессом выпуска и понимания изменений в файле MSI. Инструментарий является очень всеобъемлющим и намного более интуитивным для разработчика и обладает некоторой степенью "автоматичности", поскольку он защищает разработчика от некоторых сложностей схемы базы данных MSI, поскольку изменения вносятся в формате XML с использованием собственной схемы, а не сама база данных. В сущности, WiX переносит MSI из своих источников в современную эпоху XML, так что разработчики работают с текстовыми файлами, а файлы MSI можно рассматривать как скомпилированные исполняемые файлы, а не как исходные файлы базы данных.
На самом деле можно создавать хорошие файлы MSI, не зная слишком много о внутренней работе файла MSI - при условии, что вы следуете рекомендациям WiX - и доверяете мне, как разработчику, которому вы захотите не использовать файлы MSI. Они сложны, явно неортодоксальны и нелогичны для мышления разработчиков. Это связано со сложностью хранения всего установщика как единой базы данных. Это почти полностью декларативный и не процедурный - но некоторые части являются последовательными и определяют порядок установки. Множество движущихся частей и часовой механизм " сложности заговора " (есть ошибки, которые вы обнаружите, когда думали, что все в порядке).
Эти конструкции секвенирования являются одними из наиболее сложных частей MSI, включающих " повышенные права " и операции файловой системы, выполняемые как транзакция базы данных. Когда вы изучаете MSI как разработчика, вы обязательно почувствуете, что "с этим дизайном что-то не так", и правда заключается в том, что вся технология была разработана в соответствии с требованиями развертывания Office в те времена - и она стала такой же сложной, как и раньше. должен был быть. Кроме того, файлы MSI могут быть предварительным обзором предстоящих событий - возможно, Windows будет использовать SQL Server в качестве основного решения для хранения данных в будущем, а MSI - это первый шаг к превращению развертывания в "декларативный язык" или огромный оператор SQL для того, что произойдет в целевой системе во время развертывания? Это всего лишь предположение.
Несколько практических советов по WiX
Сохраняйте это простым, следуйте лучшим практикам, и что бы вы ни делали, не боритесь с дизайном - он сопротивляется. Если WiX не может сделать это, он, вероятно, пытается помочь вам избежать проблем развертывания. Сражайтесь с вашим менеджером, чтобы упростить или изменить требования, а не MSI - на этот раз это будет проще:-).
Большую часть времени мы обнаруживаем, что необычные схемы установки и использование пользовательских действий вызывают много ненужных сложностей или анти-шаблонов развертывания, если вам нравится, и проблемы часто можно избежать с помощью небольших изменений в дизайне приложений или использования встроенные конструкции MSI. Хороший менеджер позволит упростить развертывание, но он должен понимать, почему это необходимо. Мне нравится лицензирование как пример того, как вы можете действовать по-другому и делать развертывание проще, избегая устаревших или ненужных, сложных приложений и решений для развертывания.
Избегайте ненужных (чтение / запись) пользовательских действий любой ценой - они увеличивают сложность и риск установки в четыре раза. Спросите здесь о переполнении стека и найдите, есть ли встроенная альтернатива. В большинстве или, по крайней мере, во многих случаях в MSI есть эквивалентные встроенные конструкции для выполнения работы.
Этот конкретный совет нельзя переоценить. По моему личному мнению, настраиваемые действия только для чтения (которые могут устанавливать свойства) противоположны: они рекомендуются. Они не вызывают значительного дополнительного риска в большинстве случаев - поскольку они не вносят изменений в систему, требующую поддержки отката, и могут очень эффективно использоваться для сбора логики настройки в одном месте - и, что очень важно, они хорошо работают между коллегами, чтобы позволить подобрать работа друг друга, когда написана на простых языках сценариев, таких как JavaScript (некоторые неуклюжие аспекты при работе с MSI API) или VBScript (плохая обработка ошибок и общие языковые возможности, но хорошо протестированные с MSI API. Честно говоря, похоже, что Microsoft пытается "убить" язык. JavaScript по крайней мере "жив" и хорошо "интенсивно используется для веб-материалов).
Подводя итог, что касается сценариев: среди специалистов по развертыванию существует общее согласие, что действия сценариев всех типов, как правило, трудно отлаживать, они уязвимы для антивирусных помех и не имеют языковых функций, необходимых для реализации расширенных конструкций кодирования. В заключение: трудно написать надежный код с помощью скриптов любого типа. Возможны настраиваемые действия управляемого кода (.NET), но из-за необходимости установки.NET безопасная рекомендация - писать настраиваемые действия на C++. Это допускает минимальные зависимости, очень хорошую отладку и сложные языковые конструкции. Здесь идет долгое "обсуждение" этой проблемы: плюсы и минусы различных типов пользовательских действий (не очень, просто куча реального опыта). Хотя, может быть, это стоит того, чтобы их избежать - пользовательские действия являются основной причиной сбоев развертывания (ссылка на мою пропаганду против них), и это подводит нас к следующему пункту: общая сложность развертывания (и как с этим бороться).
Сложность развертывания
Развертывание - это сложный процесс миграции разнородных целевых компьютеров из одного стабильного состояния в другое - это требует дисциплинированного подхода, поскольку:
- Ошибки носят кумулятивный характер - вы часто вызываете больше проблем, чем больше пытаетесь исправить ситуацию с помощью быстрого исправления. Довольно скоро у вас нет возможности поддерживать в ваших руках, так как проблема, как правило, "в дикой природе" (опубликовано) и должна рассматриваться как процесс доставки - каждая итерация со своим собственным, дополнительным риском, а не просто одной проблемой для отлаживать, пока у вас не будет исправления.
- Ошибки чрезвычайно трудно отлаживать, когда у вас нет доступа к рассматриваемой системе. Ведение журнала может помочь, когда все сделано правильно, но оно часто не доставляется вам, когда вам это нужно для отладки, или оно имеет неправильный формат или многословие, или просто совершенно бесполезно, поскольку пользовательские действия часто не регистрируют вещи должным образом.
- Целевые системы (и целевая среда) различаются практически во всех возможных представлениях (это имеет место даже в том случае, если это стандартная операционная среда (SOE), которую большинство компаний используют со стандартными установками и пакетами ОС): различия в оборудовании и драйверах (большие и маленький), толстый клиент / тонкий клиент, терминальный сервер, платформа ОС (x86/x64/ и т. д.), версия ОС (Win7, Win10, WinXP и т. д.), версия ОС (окончательная, домашняя и т. д.).), Языковая версия ОС, состояние обновления ОС и уровень исправлений, ситуация с вредоносным ПО, проблемы с дисковым пространством, схема разбиения, типы файловых систем, проблемы с шифрованием (файловая система, сеть), настройка прав пользователя, конфигурация UAC, конфигурация системных привилегий ( NTRights) тип соединения, скорость соединения, конфигурация сети (домен, рабочая группа и т. д.), подсеть, настройка прокси, система и конфигурация электронной почты (Exchange, Outlook, Novell и т. д.), активный каталог, схема аутентификации, сетевые ресурсы и диски, имущество приложений, доступность сценариев, блокировка сценариев n, все виды версий времени выполнения (C, C++, MFC, ATL, ADO, OLE DB, ADO.NET, Java, среды выполнения сценариев), регистрация и настройка объектов COM и DCOM, COM+, IIS и веб-серверы, переменные пути и окружение переменные, ассоциации файлов и операции оболочки, настройка программного обеспечения беспроводной сети, количество пользователей, версии и конфигурации.NET, языковые пакеты, состояние и конфигурация GAC и WinSxS (файлы политики), программные брандмауэры, эмулируемые / виртуализированные системы, система развертывания (SCCM, Tivoli)., Так далее...). Это продолжается и продолжается.
Развертывание - это простая концепция со сложным набором переменных, которые могут вызывать самые загадочные ошибки, включая фавориты разработчика: временная ошибка. Как все мы знаем, серьезность таких ошибок нельзя переоценить, так как их часто невозможно правильно отладить.
Подробнее о развертывании и о том, что может потребоваться современной программе установки: каковы преимущества и реальная цель установки программы?, Это краткое изложение того, какие задачи может потребоваться выполнить настройку в сочетании с различными техническими деталями. Возможно, было добавлено слишком много деталей, что может разрушить "качество обзора" ответа. Однако цель заключается в том, чтобы оставаться актуальным для разработчиков.
Связанные инструменты MSI
Файл проекта Visual Studio MSI - это легкий способ создания файла MSI как части Visual Studio, и он был чрезвычайно ограничен в своем наборе функций. Были разговоры о том, чтобы заменить тип проекта MSI в Visual Studio на проект WiX XML, и это, как правило, люди теперь строят свои файлы MSI. Не используйте этот тип проекта. Это вызвало серьезные проблемы для многих пользователей из-за его гибкости и серьезных ошибок.
Orca - это инструмент Windows SDK, который позволяет открывать, редактировать и в определенной степени сравнивать двоичные файлы MSI. Фактически он был написан человеком, который позже создал сам инструментарий WiX. Роб Меншинг, когда работал в команде установщика Windows в Microsoft. Инструмент также позволяет другие операции, такие как создание файлов преобразования для изменения файлов MSI и некоторые другие технические операции. Несмотря на то, что это базовый инструмент, в котором отсутствуют наиболее продвинутые функции, доступные в коммерческих инструментах, он остается любимым в использовании упаковщиком приложений и доступен для отладки и небольших исправлений благодаря своей надежности, простоте и " чистоте " - он не добавляет "по умолчанию" "спам" в MSI при его сохранении (сторонние инструменты добавляют пользовательские таблицы и подобные спам). Я использую его для небольших обновлений MSI, отладки, проверки сводного потока, создания базовых преобразований, просмотра исправлений, проверки пакетов и других важных операций.
На самом деле, я думаю, что это продвинутый инструмент с простым интерфейсом, а не базовый инструмент:-). Чтобы освоить Orca, вам нужно установить Windows SDK (!). На самом деле, немного поразительно, когда размер инструмента настолько мал, но, по крайней мере, легко узнать, где он доступен, вместо того, чтобы искать отдельную загрузку.
ОБНОВЛЕНИЕ: Если у вас установлена Visual Studio и SDK, найдите Orca-x86_en-us.msi и установите его. Если вы этого не сделаете, может быть, ваш друг с установленной Visual Studio ищет его, а затем отправляет вам? Это небольшой файл.
Есть также несколько альтернативных бесплатных инструментов, доступных как описано здесь (внизу): Как я могу сравнить содержимое двух (или более) файлов MSI?
DTF - Deployment Tools Foundation - это набор классов.NET для программной работы с файлами MSI. Хорошо написанный, простой в использовании и очень мощный, теперь он включен в основную загрузку WiX. Это важный компонент в любом проекте для автоматизации корпоративного использования файлов MSI. Вот краткий ответ на serverfault.com, где обсуждается его использование и описываются его основные компоненты. Файлы справки, включенные в DTF, помогут вам быстро приступить к работе с инструментарием, и вы никогда не будете оглядываться на использование функций Win32 или COM-классов для доступа к файлам MSI.
На рынке есть много других инструментов Windows Installer, и некоторые из них вы можете найти по сравнению с WiX в разделе Какой установочный продукт использовать? InstallShield, WiX, Wise, Advanced Installer и т. Д. ( Та же ссылка, что и выше).
WiX создает пакеты MSI, которые используют установщик Windows. Таким образом, WiX использует механизм установщика Windows.
Visual Studio - это просто альтернатива WiX, просто еще один инструмент создания настроек. Я не рекомендую это, потому что это чрезвычайно ограничено. Он предлагает только основные функции.
Если вы довольны WiX, оставайтесь с ним.