Установщик Windows и создание WiX

Ответ 1

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

Это предназначено для быстрого ознакомления с WiX и MSI с точки зрения разработчика . Существует также несколько популярная статья serverfault.com, которая может быть полезной для получения преимуществ Windows Installer: Корпоративные преимущества использования файлов MSI (многие разработчикам не нравится установщик Windows, но преимущества корпоративного развертывания на самом деле весьма значительны - возможно, стоит быстро сэкономить, если вы считаете, что MSI больше проблем, чем того стоит).

Происхождение набора инструментов WiX

Файлы MSI по существу разделяются SQL серверные базы данных, хранящиеся как COM -структурированные файлы хранения. Это формат файла, используемый в Microsoft Office, и он был разработан как способ хранения иерархических данных в одном файле. По существу файловая система внутри файла с потоками хранения различных типов - одним из которых является файлы для установки внутри одного или нескольких файлов 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. Хороший менеджер позволит упростить развертывание, но им нужно понять, почему это необходимо. Мне нравится лицензирование в качестве примера того, как вы можете поступать по-другому и упростить развертывание, избегая старомодных или ненужных, сложных приложений и решений для развертывания.

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

Этот конкретный совет нельзя переоценить. По моему личному мнению, пользовательские действия только для чтения (которые могут устанавливать свойства) противоположны: они рекомендуются. В большинстве случаев они не вызывают значительного дополнительного риска - поскольку они не вносят никаких изменений в систему, требующую поддержки отката, и могут быть очень эффективно использованы для сбора логики установки в одном месте - и в решающей степени они хорошо работают между сотрудниками, чтобы обеспечить сбор друг друга работают при написании на простых языках сценариев, таких как JavaScript или даже VBScript (менее желательно из-за плохой обработки ошибок и общих функций языка. VBScript по-прежнему доступен, но, откровенно говоря, похоже, что Microsoft пытается "убить" язык. является, по крайней мере, "живым и здоровым" при интенсивном использовании веб-материалов).

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

Сложность развертывания

Развертывание - это сложный процесс миграции гетерогенных целевых компьютеров из одного стабильного состояния в другой - для этого требуется дисциплинированный подход, поскольку:

• Ошибки являются кумулятивными по своей природе - вы часто вызываете больше проблем, чем больше пытаетесь исправить ситуацию с помощью быстрого исправления. Довольно скоро у вас есть невозможность поддерживать ваши руки, так как проблема обычно "в дикой природе" (опубликована) и должна рассматриваться как процесс доставки - каждая итерация с собственным, добавленным риском, а не только одна проблема для отлаживать, пока у вас не будет исправления.
• Ошибки очень трудно отлаживать, когда у вас нет доступа к рассматриваемой системе, Ведение журнала может помочь, когда все сделано правильно, но часто не доставляется вам, когда вам это нужно для отладки, или оно находится в неправильном формате или многословие, или просто бесполезно вообще, поскольку пользовательские действия часто не регистрируют вещи должным образом.
• Целевые системы (и целевая среда) различаются практически во всех возможных возможностях (это так, даже если это стандартная операционная среда (SOE), поскольку большинство компаний используют стандартизованные установки ОС и пакеты): различия в оборудовании и драйверах (большие и малые), толстый клиент/тонкий клиент, сервер терминалов, платформа ОС (x86/x64/etc...), версия ОС (Win7, Win10, WinXP и т.д.), Версия ОС (конечная, домашняя и т.д.), Версия языкового стандарта ОС, статус обновления ОС и уровень патча, ситуация с вредоносным ПО, проблемы с дисковым пространством, схема разбиения на разделы, типы файловой системы, проблемы с шифрованием (файловая система, сеть), настройка прав пользователя, Конфигурация UAC, конфигурация системных привилегий (NTRights), тип подключения, скорость соединения, сетевая конфигурация (домен, рабочая группа и т.д.)), суб-сетью, настройкой прокси, системой электронной почты и конфигурацией (Exchange, Outlook, Novell и т.д.), активным каталогом, схемой аутентификации, сетевыми долями и дисками, (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. Rob Mensching, когда он работал в команде Windows Installer в Microsoft. Этот инструмент также позволяет выполнять другие операции, такие как создание файлов преобразования для изменения файлов MSI и некоторых других технических операций. Несмотря на то, что это очень простой инструмент, в котором отсутствуют самые современные функции, доступные в коммерческих инструментах, он остается приложением для использования и доступен для отладки и небольших исправлений благодаря своей надежности, простоте и чистоте "- он не добавляет" по умолчанию "к MSI при его сохранении (сторонние инструменты добавляют пользовательские таблицы и аналогичные нежелательные файлы). Я использую его для небольших обновлений MSI, отладки, проверка сводного потока, создание основных преобразований, просмотр патчей, проверка пакетов и другие важные операции.

На самом деле, я думаю, это продвинутый инструмент с простым интерфейсом, а не базовый инструмент:-). Чтобы завладеть Orca, вам необходимо установить Windows SDK (!). Немного поверх всего, когда размер инструмента настолько мал, но, по крайней мере, легко узнать, где он доступен, а не искать отдельную загрузку.

DTF - Foundation Tools - это набор классов .NET для программной обработки файлов MSI. Хорошо написанный, простой в использовании и очень мощный теперь включен в основную загрузку WiX. Это важный компонент в любом проекте для автоматизировать корпоративное использование файлов MSI. Вот краткий ответ на serverfault.com, в котором обсуждается его использование и описание его основных компонентов. справочные файлы, включенные в DTF, помогут вам быстро перейти к набору инструментов, и вы никогда не оглядитесь на использование функций Win32 или COM-классов для доступа к файлам MSI.

На рынке есть много других инструментов установщика Windows, и некоторые из них вы можете найти по сравнению с WiX в Какой установочный продукт использовать? InstallShield, WiX, Wise, Advanced Installer и т.д. (такая же ссылка, как указано выше).

Ответ 2

WiX создает пакеты MSI, которые используют установщик Windows. Поэтому WiX использует механизм установщика Windows.

Visual Studio - это просто альтернатива WiX, просто еще один инструмент создания настроек. Я не рекомендую его, потому что он крайне ограничен. Он предлагает только основные функции.

Если вы довольны WiX, оставайтесь с ним.