На самом деле это уже далеко не первый случай, когда "Майкрософт" засвечивается в сообществе Open Source. В памяти сразу же всплывает недавнее явление Services For UNIX. Но нас сейчас больше будет интересовать суть вопроса, то есть: что же такое XML-инсталлятор и как он работает.

WiX, Windows Installer XML — это набор инструментов для создания пакетов инсталляции Windows из XML-кода. Инсталляторы, как известно, служат для установки дистрибутива. А дистрибутив, как известно, состоит из объектов, таких как исполняемые файлы, ресурсы, библиотеки, ключи системного реестра, а также из интерактивных диалогов, с помощью которых пользователь может задать параметры инсталляции, вроде каталога приложения или состава устанавливаемых компонент.

Элемент новизны, или, по крайней мере, хорошая практика, заключается в том, что описание дистрибутива выглядит теперь как обычный XML-документ, в который легко можно вносить изменения. Создаваемый XML-файл должен удовлетворять требованиям WiX-схемы, которая, собственно, и есть основа открытого кода. Вторым компонентом является собственно построитель инсталляции, на входе которого — указанный XML-файл, плюс все файлы, входящие в дистрибутив, а на выходе — MSI, файл инсталляции сравнительно нового и, как говорят в "Майкрософт", окончательного формата.

Основным объектом верхнего уровня в терминах WiX является продукт — то есть одна инсталляция устанавливает один продукт. С продуктом связан уникальный идентификатор, который, как принято в MS Windows, представляет собой 128-битное число. Уникальность ключа продукта абсолютная, то есть ключ должен быть уникальным в масштабах всей Windows-вселенной. Такие глобально уникальные ключи сокращенно называют GUID’ами — Global Unique ID. Существует специальная утилита для их генерации, а также онлайн-сервис регистрации и резервирования ключей для гарантии уникальности последних.

Следующим (после продукта) уровнем детализации является пакет. Он может включать один или несколько файлов — обычно файлы инсталляции MSI, MSM (MS Merge Modules) и архивы CAB. Пакет тоже идентифицируется уникальным значением GUID.

Дополнительно весь продукт состоит из опций (features). Опции — это то, что видит пользователь при инсталляции и что он может выбрать (или не выбирать) для инсталляции.

Опции имеют иерархическую структуру: одни features включают другие и так далее. К примеру, при инсталляции Visual Studio вы можете выбрать установку компонент для создания программ на C++. Внутри этой опции вы можете выбрать установку статически и динамически связываемых библиотек, дополнительные средства отладки и так далее. Другой типичный пример опции — установка файлов помощи, help-файлов. При ограниченном объеме диска пользователь может предпочесть чтение help’а с лазерного диска.

Опции могут по умолчанию быть как выбранными, там и не выбранными. С каждой из них связана описательная строка, уникальная в рамках данной инсталляции.

Каждый отдельный элемент инсталляции, такой как файл, ключ реестра и т.д., называется компонентом. Компоненты также имеют уникальные ключи GUID — не зависимо от устанавливаемого пакета.

Исторически для создания пакетов MSI использовался набор инструментов Windows Installer SDK. Это несколько утилит для компоновки инсталляции и специальный редактор Orca. С помощью этих средств можно задействовать все заложенные в MSI возможности, хотя использование штатных средств не настольно удобно, как хотелось бы. Более того, сторонние производители инсталляционного ПО, такого как InstallShield и Wise, тоже включили в свои продукты поддержку нового формата. Эти средства включают интерактивные помощники, конструкторы диалогов и другие инструменты, упрощающие процесс.

Казалось бы, проблема решена, но "Майкрософт" предлагает новый, обобщенный подход для тех же целей. В чем же проблема?

Проблема, по мнению компании, заключается в подходе к построению дистрибутивов. Все перечисленные средства являются интерактивными, то есть требуют выполнения пользователем операций для генерации результирующих файлов. Такой подход вполне подходит для небольших проектов, но не годится для поточного построения релизов. В первую очередь эта проблема коснулась самой "Майкрософт", где построение дистрибутивов — ежедневная, если не ежеминутная, операция. Особенный интерес к сборке "на лету" вызван возможностью динамической генерации дистрибутивов, как результата запроса пользователя через веб-интерфейс. Нелишним было бы и автоматизированное построение дистрибутивов в таких оболочках, как Visual Studio NET (что, кстати, уже реализовано с помощью нового мастера инсталляций).

Так появился WiX. Будучи на протяжении нескольких лет продуктом для внутреннего использования в самой "Майкрософт", сегодня WiX стал свободно доступным для публичного использования.

Основное преимущество, кроме возможности быстрой генерации — применение в качестве декларативного языка систему разметки XML. Это позволяет модифицировать состав инсталляции с помощью стандартных интерфейсов (DOM, SAX). Поскольку эти методы доступа к данным XML встроены в большинство современных языков, в том числе в операционную среду DOT NET, это делает написание управляющих алгоритмов простым, доступным и согласованным процессом. Еще раз напомню, что генерация инсталляций происходит с помощью утилит командной строки, так что процесс можно полностью автоматизировать.

Как работает WiX

В среду создания дистрибутивов входит четыре компонента. Это, во-первых, сама схема XML/WiX, вокруг которой построены основные утилиты. Компилятор candle компилирует исходные файлы в объектные. Линкер light связывает файлы в один MSI- или MSM-файл. Декомпайлер — dark — напротив, строит WiX-файлы на основании существующих MSI- или MSM-файлов.

В основе всего процесса генерации лежит обычно один XML-файл особого формата, в терминах XML называемого схемой. Обычно файлы WiX имеют расширение *.wxs. Самый простой и тривиальный файл содержит всего один тэг — ссылку на прототип WiX-документа и имеет вид:

Вы можете создать этот файл и откомпилировать его с помощью компилятора candle, чтобы убедиться в работоспособности данного файла. Если ваш файл называется, к примеру, 1.wxs, то командная строка будет выглядеть как candle 1.wxs. Если не обнаруживаются ошибки, то процесс компиляции не будет сопровождаться каким-либо сообщениями, кроме заголовка компилируемого файла (да и его можно подавить, задав ключ -nologo).

В результате вы получите файл с тем же именем, что и ваш WXS, но только с расширением wixobj. Этот файл содержит всю информацию о составе дистрибутива, но не сами файлы — таким образом вы можете компилировать wix-файлы реже, чем выполнять сборку, поскольку компиляция нужна, только если вы изменяете состав инсталляции. Обновление самих файлов не требует повторного применения candle.
Говоря попросту, объектный файл тоже является XML-файлом, в котором компилятор добавляет дополнительную информацию о включаемых объектах. В числе прочего, ссылка на оригинальный файл позволяет отслеживать проблемы и их источник. Чтобы убедиться в этом, откройте результирующий wixobj в любом редакторе:

Установка фиктивного продукта

Рассмотрим несколько более сложный пример, приведенный в документации по WiX, который создает пустой продукт, не содержащий файлов, но, тем не менее, отображающийся в "Панели управления":

Как видим, все подтверждает наши предпосылки: главным объектом является продукт, содержащий подсекции в виде пакетов, каталогов и опций. Иерархическая структура позволяет строить замысловатые и сложные структуры. Процесс компиляции заменяет содержательные тэги на более "техногенные", такие как section, reference, tuple или table. При просмотре обратите внимание на информацию о номерах строк исходного файла — это также позволяет производить отладку и поиск ошибок.

Вы можете откомпилировать и связать указанный файл с помощью команд (их вполне можно объединить в тривиальный BAT-файл):

>candle 1.wxs
>light 1.wixobj
>msiexec /i 1.msi

В результате вы запустите системный инсталлятор и установите новый фиктивный продукт. Зайдите в "Панель управления" и убедитесь, что у вас появилось новое приложение Test Package — удалите его на всякий случай (убедившись заодно, корректно ли отрабатывает эта операция).

Реальные объекты

Наконец рассмотрим третий пример, который, помимо записи в "Установленных программах", создает еще один реальный объект, в частности записывает файл в каталог приложения. В качестве файла мы, вслед за документацией, будем использовать простой текстовый файл с произвольным содержанием, в нашем случае его имя — readme.txt. Создайте такой файл в каталоге, где расположен ваш проект. Файл WXS будет иметь такой вид:

Откомпилируйте и свяжите этот файл в MSI — после инсталляции вы получите ожидаемый эффект: в каталоге приложения C:Program FilesTest Program появится текстовый файл. Удалить приложение можно, как и прежде, через "Панель управления". Дополнительно вы можете проделать то же самое, выполнив команду:

>msiexec /x 1.msi

Мы не будем рассматривать дополнительные тэги более подробно — во-первых, их около двухсот, во-вторых, для этого существует документация. Главное, чтобы вы попробовали и поняли, как работает данная технология, какие выгоды при построении приложений она сулит, а также насколько эта технология проста и доступна — даже для начинающих разработчиков.

Итог

Созданная для самих разработчиков "Майкрософт" и не раз уже проверенная внутри компании, технология WiX отличается от ряда других продуктов софтверного гиганта своей надежностью, скоростью и тем, что она, как говорится, сделана на совесть. Ко всему прочему, открытый код позволяет вам свободно исследовать исходный текст утилит и при необходимости приспосабливать его под свои нужды.

С точки же зрения самой тенденции, то применение открытых стандартов, таких как XML, и открытых лицензий, таких как CPL, можно только приветствовать.

Ведь могут же, когда захотят.