Установщик 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 является важным шагом в процессе выпуска.