Установщик Windows ( msiexec.exeранее известный как Microsoft Installer , [3] кодовое имя Darwin ) [4] [5] — это программный компонент и интерфейс прикладного программирования (API) Microsoft Windows, используемый для установки , обслуживания и удаления программного обеспечения. Информация об установке и, при необходимости, сами файлы упаковываются в установочные пакеты , слабо реляционные базы данных , структурированные как структурированные хранилища COM и широко известные как «файлы MSI», в зависимости от их расширений по умолчанию . Пакеты с расширениями файлов mstсодержат «Сценарии преобразования» установщика Windows, пакеты с msmрасширениями содержат «Модули слияния», а расширение файла pcpиспользуется для «Свойства создания исправлений». [6] Установщик Windows содержит существенные изменения по сравнению со своим предшественником, API настройки. Новые функции включают в себя структуру графического пользовательского интерфейса и автоматическое создание последовательности удаления . Установщик Windows позиционируется как альтернатива автономным исполняемым средам установки, таким как старые версии InstallShield и NSIS .
До появления Microsoft Store (тогда называвшегося Windows Store) Microsoft поощряла третьи стороны использовать установщик Windows в качестве основы для установочных платформ, чтобы они правильно синхронизировались с другими установщиками и поддерживали согласованность внутренней базы данных установленных продуктов. Надежная работа важных функций, таких как откат и управление версиями, зависит от согласованной внутренней базы данных. Кроме того, установщик Windows реализует принцип минимальных привилегий , выполняя установку программного обеспечения через прокси для непривилегированных пользователей.
Пакет описывает установку одного или нескольких полных продуктов и универсально идентифицируется по GUID . Продукт состоит из компонентов , сгруппированных по функциям . Установщик Windows не обрабатывает зависимости между продуктами.
Отдельная установленная работающая программа (или набор программ) является продуктом . Продукт идентифицируется уникальным идентификатором GUID (свойство ProductCode), обеспечивающим авторитетную идентификацию во всем мире. GUID в сочетании с номером версии (свойство ProductVersion) позволяет управлять выпуском файлов и ключей реестра продукта.
Пакет включает в себя логику пакета и другие метаданные , относящиеся к тому , как пакет выполняется при запуске. Например, изменение EXE-файла в продукте может потребовать изменения ProductCode или ProductVersion для управления выпуском. Однако простое изменение или добавление условия запуска (при этом продукт остается точно таким же, как и предыдущая версия) все равно потребует изменения PackageCode для управления выпуском самого файла MSI.
Объект представляет собой иерархическую группу компонентов. Функция может содержать любое количество компонентов и других подфункций. Меньшие пакеты могут состоять из одной функции. Более сложные программы установки могут отображать диалоговое окно «настраиваемая настройка», в котором пользователь может выбрать, какие функции установить или удалить.
Автор пакета определяет возможности продукта. Например, текстовый процессор может поместить основной файл программы в одну функцию, а файлы справки программы, дополнительную проверку орфографии и канцелярские модули — в дополнительные функции.
Компонент – это базовая единица продукта. Каждый компонент рассматривается установщиком Windows как единое целое. Установщик не может установить только часть компонента. [7] Компоненты могут содержать программные файлы , папки , COM- компоненты, ключи реестра и ярлыки . Пользователь не взаимодействует напрямую с компонентами.
Компоненты идентифицируются глобально по идентификаторам GUID; таким образом, один и тот же компонент может использоваться несколькими функциями одного и того же пакета или нескольких пакетов, в идеале за счет использования модулей слияния .
Путь к ключу — это конкретный файл, ключ реестра или источник данных ODBC , который автор пакета указывает как критический для данного компонента. Поскольку файл является наиболее распространенным типом пути к ключу, обычно используется термин «файл ключа» . Компонент может содержать не более одного ключевого пути; если у компонента нет явного пути к ключу, в качестве пути к ключу принимается папка назначения компонента. При запуске программы на основе MSI установщик Windows проверяет наличие путей к ключам. Если существует несоответствие между текущим состоянием системы и значением, указанным в пакете MSI (например, отсутствует ключевой файл), соответствующая функция устанавливается повторно. Этот процесс известен как самоисцеление или самовосстановление . Никакие два компонента не должны использовать один и тот же ключевой путь.
Создание установочного пакета для нового приложения — нетривиальная задача. Необходимо указать, какие файлы необходимо установить, куда и с какими ключами реестра. Любые нестандартные операции можно выполнить с помощью Custom Actions, которые обычно разрабатываются в DLL . Существует ряд коммерческих и бесплатных продуктов, помогающих создавать пакеты MSI, включая Visual Studio (изначально до VS 2010, [8] с расширением для более новых версий VS [9] ), InstallShield и WiX . В той или иной степени пользовательский интерфейс и поведение могут быть настроены для использования в менее распространенных ситуациях, таких как автоматическая установка. После подготовки пакет установщика «компилируется» путем чтения инструкций и файлов с локального компьютера разработчика и создания файла .msi.
Пользовательский интерфейс (диалоговые окна), представленный в начале установки, может быть изменен или настроен инженером по установке, разрабатывающим новый установщик. Язык кнопок, текстовых полей и меток ограничен, которые можно организовать в виде последовательности диалоговых окон. Пакет установщика должен работать без какого-либо пользовательского интерфейса, что называется «автоматической установкой».
Microsoft предоставляет набор оценщиков внутренней согласованности (ICE), которые можно использовать для обнаружения потенциальных проблем с базой данных MSI. [10] Правила ICE объединены в файлы CUB, которые представляют собой урезанные файлы MSI, содержащие настраиваемые действия, которые проверяют содержимое целевой базы данных MSI на наличие предупреждений и ошибок проверки. Проверка ICE может выполняться с помощью инструментов Platform SDK Orca и msival2 или с помощью инструментов проверки, которые поставляются с различными средами разработки.
Например, некоторые из правил ICE:
Устранение предупреждений и ошибок проверки ICE является важным шагом в процессе выпуска.