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