Я просто хочу добавить более конкретную техническую информацию о самой технологии 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 , Advanced Installer и Wise Package Studio (больше не доступны из-за юридических проблем - см. сравнение доступных в настоящее время инструментов MSI ). Эти инструменты сохраняли файл MSI в его собственном «устанавливаемом» формате как файл структурированного хранилища COM.Это означало, что ваш файл MSI был и исходным, и исполняемым, и в двоичном формате.Это затрудняло исходный контроль вашего проекта установки.Двоичные различия в различных базах данных MSI были сложными, и из-за базы данных ссылочной целостности даже самые базовые изменения в MSI будут каскадно проходить через десятки таблиц и затруднять просмотр того, что изменилось даже для тренированных глаз.*
WiX стал способом, позволяющим разработчикам создавать двоичный файл MSI из обычных текстовых исходных файлов. Так же, как обычный двоичный файл EXE, двоичный файл MSI «компилируется» из текста WiX.XML-файлы.Это квантовый скачок с точки зрения управления процессом выпуска и понимания изменений в файле 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 (некоторые неуклюжие аспекты при работе с API MSI) или VBScript (плохая обработка ошибок и общий язык функций, но хорошо протестированы с MSI API. Честно говоря, похоже, что Microsoft пытается «убить» язык. JavaScript, по крайней мере, «жив и здоров» в интенсивном использовании для веб-материалов).
Подводя итоги в отношении сценариев: среди специалистов по развертыванию существует общее мнение, что действия сценариев всех типов в общем случае трудны для отладки , уязвимы для антивирусных помех и не хватает языковых возможностей , необходимых для реализации расширенных конструкций кодирования. В заключение: сложно написать надежный код с использованием скриптов любого типа. Пользовательский управляемый код Действия возможны (.NET), но из-за необходимости установки .NET безопасная рекомендация - писать собственные действия на C ++. Это допускает минимальные зависимости, очень хорошую отладку и сложные языковые конструкции. Здесь долгое «обсуждение» этой проблемы: плюсы и минусы различных типов пользовательских действий (не очень, просто куча реального опыта). Хотя, возможно, стоит попробовать - пользовательские действия являются основной причиной сбоев развертывания (ссылка на мою пропаганду против них), и это подводит нас к следующему пункту: общая сложность развертывания (и как с этим бороться).
Сложность развертывания
Развертывание - это сложный процесс миграции разнородных целевых компьютеров из одного стабильного состояния в другое - для этого требуется дисциплинированный подход , поскольку:
- Ошибки носят кумулятивный характер - чем чаще вы пытаетесь исправить ситуацию с помощью быстрого исправления, тем чаще возникают проблемы. Довольно скоро у вас нет возможности поддерживать в ваших руках, так как проблема, как правило, «в дикой природе» (опубликовано) и должна рассматриваться как процесс доставки - каждая итерация со своим собственным, дополнительным риском, а не просто одной проблемой для отлаживать, пока у вас не будет исправления.
- Ошибки чрезвычайно трудно отлаживать , когда у вас нет доступа к рассматриваемой системе . Ведение журнала может помочь, когда все сделано правильно, но часто оно не доставляется вам, когда вам это нужно для отладки, или оно имеет неправильный формат или многословие, или просто совершенно бесполезно, поскольку пользовательские действия часто не регистрируют вещи должным образом.
- Целевые системы (и целевая среда) различаются практически во всех возможных (это имеет место даже в том случае, если это стандартная операционная среда (SOE), которую большинство компаний используют со стандартизованными установками ОС и пакетами). ): различия между оборудованием и драйверами (большие и маленькие), толстый клиент / тонкий клиент, терминальный сервер, платформа ОС (x86 / x64 / и т. д.), версия ОС (Win7, Win10, WinXP и т. д.), ОС редакция (окончательная, домашняя и т. д.), языковая версия ОС, состояние обновления ОС и уровень исправлений, ситуация с вредоносным ПО, проблемы с дисковым пространством, схема разбиения, типы файловой системы, проблемы с шифрованием (файловая система, сеть), настройка прав пользователя, Конфигурация UAC, конфигурация системных привилегий ( NTRights ), тип соединения, скорость соединения, конфигурация сети (домен, рабочая группа и т. Д.), Подсеть, настройка прокси, система электронной почты и конфигурация (Exchange, Outlook , Novell и т. Д.), Активный каталог, схема аутентификации, сетевые ресурсы и диски, имущество приложений, сценарии avai лабильность, блокировка сценариев, все виды версий времени выполнения (C, C ++, MFC, ATL, ADO, OLE DB, ADO.NET, Java, среды выполнения сценариев), регистрация и настройка объектов COM и DCOM, COM +, IIS и веб-серверы , переменные пути и переменные среды, ассоциации файлов и операции оболочки, настройка программного обеспечения беспроводной сети, количество пользователей, версии и конфигурация .NET, языковые пакеты, состояние и конфигурация GAC и WinSxS (файлы политики), программные брандмауэры, эмулируемые / виртуализированные системы, развертывание система (SCCM, Tivoli, Etc ...). Это продолжается и продолжается.
Развертывание - это простая концепция со сложным набором переменных, которые могут вызвать самые загадочные ошибки, включая фавориты разработчика: неустойчивая ошибка .Как все мы знаем, серьезность таких ошибок невозможно переоценить, поскольку их часто невозможно правильно отладить.
Подробнее о развертывании и о том, что может потребоваться современной программе установки: В чем выгода и реальная цель установки программы? .Это краткое изложение того, какие задачи может потребоваться выполнить настройку в сочетании с различными техническими деталями.Возможно, было добавлено слишком много деталей, что может разрушить «качество обзора» ответа.Однако цель заключается в том, чтобы оставаться актуальными для разработчиков.
Связанные инструменты MSI
Файл проекта Visual Studio MSI - это легкий способ создания MSI.файл как часть Visual Studio, и он был чрезвычайно ограничен в своем наборе функций.Говорили о том, чтобы заменить тип проекта MSI в Visual Studio проектом WiX XML, и сейчас люди обычно создают свои файлы MSI.Не используйте этот тип проекта.Это вызвало серьезные проблемы для многих пользователей из-за его гибкости и серьезных ошибок.
Orca - это Windows SDK инструмент, который позволяетдвоичные файлы MSI, которые нужно открывать, редактировать и в определенной степени сравнивать.Фактически он был написан человеком, который позже создал сам инструментарий WiX. Роб Меншинг , когда он работал в команде Windows Installer в Microsoft .Инструмент также позволяет другие операции, такие как создание файлов преобразования для изменения файлов MSI и некоторые другие технические операции.Хотя это очень простой инструмент, в котором отсутствуют самые продвинутые функции, доступные в коммерческих инструментах, он остается любимым пакетом приложений для использования и доступен для отладки и небольших исправлений из-за его надежности , простоты и " чистоты " - он не добавляет "мусор по умолчанию" в MSI при его сохранении (сторонние инструменты добавляютпользовательские столы и тому подобное барахло).Я использую его для небольших обновлений MSI , отладка , проверка суммарного потока , создание базовых преобразований просмотр патчей , проверка пакета и другие важные операции.
На самом деле, я думаю, что это продвинутый инструмент с простым интерфейсом, а не простойинструмент вообще :-).Чтобы овладеть Orca, вам необходимо установить Windows SDK (!).Немного непомерно, когда размер инструмента очень мал, но, по крайней мере, легко узнать, где он доступен, вместо того, чтобы искать отдельную загрузку.
ОБНОВЛЕНИЕ :Если у вас установлена Visual Studio и SDK, найдите Orca-x86_en-us.msi и установите его.Если вы этого не сделаете, возможно, попросите друга с установленной Visual Studio найти его, а затем отправить его вам?Это небольшой файл.
Есть также несколько альтернативных бесплатных инструментов, доступных, как описано здесь (внизу): Как сравнить содержимое двух (или более) файлов MSI?
DTF - Фонд средств развертывания - это набор классов .NET для программной работы с файлами MSI.Хорошо написанный, простой в использовании и очень мощный - теперь включен в основную загрузку WiX .Это важный компонент в любом проекте для автоматизации корпоративного использования файлов MSI. Вот краткий ответ на serverfault.com , где обсуждается его использование и описываются его основные компоненты. файлы справки , включенные в DTF, помогут вам быстро приступить к работе с инструментарием, и вы никогда не будете оглядываться на использование функций Win32 или COM-классов для доступа к файлам MSI.
На рынке есть много других инструментов Windows Installer, и некоторые из них вы можете найти по сравнению с WiX на Какой установочный продукт использовать?InstallShield, WiX, Wise, Advanced Installer и т. Д. (та же ссылка, что и выше).