Windows installer xml создание программы установки в visual studio евгений воднев

Обновлено: 03.07.2024

Неожиданно для себя наткнулся на замечательный инструмент для создания инсталляций - Windows Installer XML (WiX) toolset. Еще на прошлой неделе я был уверен, что поиски удобной среды для создания инсталляций под Windows Installer обернутся просмотром длинного списка коммерческих утилит и «наколенных» поделок. В качестве эталона для сравнения выступала Inno Setup – довольно удобная и простая в использовании программа. Кроме того Inno Setup бесплатна, что делало шансы на победу коммерческого инсталлятора мизерными.

В общем, я был заранее уверен что ничего путного не найдется и придется использовать традиционный Inno Setup. Тем не менее на глаза попался WiX и стало понятно, что Inno Setup пора отправлять на покой. Заранее скажу, что тут дело не в том, какой WiX хороший, а в том, что он использует Windows Installer. А Windows Installer это все-таки стандарт.

Во-первых, инсталляция описывается в виде XML имеющем логичную структуру. В большинстве случаев, чтобы понять код, документация не требуется. Кроме того, в Visual Studio для файлов WiX работает автодополнение, так что и для написания кода документация не нужна;

Вo-вторых, несмотря на то, что нужда в документации возникает не часто, она (документация) есть! Причем это достаточно подробная и удобная документация. Для начинающих, в наличии имеется пошаговое описание с чего начать и как все работает;

В-третьих, WiX это качественно написанная программа. Это трудно объяснить, это надо почувствовать. По крайней мере меня не покидает ощущение, что все необходимые мелочи продуманы и доделаны, а непродуманные и недоделанные мелочи, если они есть, и так никому не нужны; :-)

В-четвёртых, существуют GUI надстройки над WiX, в том числе плагин для Visual Studio – Votive;

В-пятых, есть ещё много мелких преимуществ вроде легкости автоматизации или бесплатности WiX.

WiX это просто очень тонкая прослойка между программистом и Windows Installer. Она не расширяет функциональность Windows Installer и не скрывает его возможности. WiX просто здорово облегчает процесс создания инсталляций, делая его осознанным и управляемым.

Для начала — что такое WiX? Технология WiX (Windows Installer XML) представляет собой набор инструментов и спецификаций упрощающих процесс создания дистрибутивов на базе MSI (Microsoft Installer). Если объяснять проще то это обертка вокруг MSI с человеческим лицом.

На мой взгляд изучать проще всего на простых примерах. В данной статье я приведу пример простейшего инсталлятора.

Для начала поставим условия задачи — необходимо создать установочный дистрибутив, который будет содержать следующие диалоги:

Приветствие

Лицензионное соглашение

Выбор директории

Начало установки

Для создания дистрибутива нам понадобится сам WiX, последнюю версию которого всегда можно скачать на Source Forge. На данный момент последняя версия 3.5.0828.0.

Необходимо скачать и установить:
1. ProjectAggregator2.msi — нужен, для того, чтобы установить Votive (находится внутри дистрибутива номер 2). Который, в свою очередь, является дополнением для Visual Studio, облегчающим процесс работы с WiX (подсветка синтаксиса, IntelliSense).
2. Wix35.msi или Wix35_x64.msi (в зависимости от платформы)
3. Русский языковой файл

Итак, скачали, установили, запускаем Visual Studio. Меню File -> New Project, если все установлено правильно — появился новый раздел Windows Installer XML. Выбираем шаблон проекта Setup Project, вводим название проекта (я оставил как есть SetupProject1).

Проект будет состоять из одного файла Product.wxs с ним мы и будем работать. В моем случае файл выглядел следующим образом:

<? xml version ="1.0" encoding ="UTF-8" ? >
< Wix xmlns ="http://schemas.microsoft.com/wix/2006/wi" >
< Product Id ="b7bc7c6f-9a4e-4973-be84-eca8e3427c97" Name ="SetupProject1" Language ="1033" Version ="1.0.0.0" Manufacturer ="SetupProject1" UpgradeCode ="06a81104-1e30-463d-87e1-e8a79b4c682a" >
< Package InstallerVersion ="200" Compressed ="yes" />

< Media Id ="1" Cabinet ="media1.cab" EmbedCab ="yes" />

< Directory Id ="TARGETDIR" Name ="SourceDir" >
< Directory Id ="ProgramFilesFolder" >
< Directory Id ="INSTALLLOCATION" Name ="SetupProject1" >




</ Directory >
</ Directory >
</ Directory >

< Feature Id ="ProductFeature" Title ="SetupProject1" Level ="1" >


</ Feature >
</ Product >
</ Wix >

* This source code was highlighted with Source Code Highlighter .

Для начала настроим внешний вид и добавим поддержку русского языка.

Начнем с добавления русского языка. Для этого:
1. В ключе Product изменяем 1033 на 1049
2. В свойствах проекта (правой клавишей по названию проекта в Solution Explorer -> Properties), закладка Build, в поле Cultures to build вставляем ru-RU
3. Добавляем к проекту (правой клавишей по названию проекта в Solution Explorer -> Add -> Existing Item) файл WixUI_ru-ru.wxl (из архива WixUI_ru-ru.v3.zip)

В сгенерированном проекте нет ни одного диалогового окна. Существуют два варинта добавления диалоговых окон — создавать самостоятельно, либо воспользоваться готовым набором диалоговых окон.

Мы пойдем вторым путем, начинать знакомство лучше с простого. Для этого необходимо добавить ссылку на WixUIExtension.dll (правой клавишей по названию проекта в Solution Explorer -> Add Reference — открываем папку, в которую был установлен WiX, подкаталог bin)

Ссылку добавили, указываем какой набор мы будем использовать, в конце раздела Product добавим

< Property Id ="WIXUI_INSTALLDIR" Value ="INSTALLLOCATION" ></ Property >
< WixVariable Id ="WixUILicenseRtf" Overridable ="yes" Value ="License.rtf" />

< UIRef Id ="WixUI_InstallDir" />

* This source code was highlighted with Source Code Highlighter .

WixVariable — указывает на путь к файлу лицензии (речи о нем пока не шло, добавили сразу, чтобы два раза не ходить).
WixUI_InstallDir — готовый набор диалоговых окон. Данный набор включает все необходимые нам диалоги. Помимо него так же существуют наборы WixUI_Advanced, WixUI_Mondo, WixUI_FeatureTree, WixUI_InstallDir, WixUI_Minimal.

Приготовления закончены, можно приступать к редактированию файла установки. Для начала посмотрим, что нам нагенерила студия:

Ключ Product — описывает свойства продукта.
Id — идентификатор продукта, уникальный GUID.
Name — название продукта
Language — язык пакета установки
Version — версия продукта
Manufacturer — производитель
UpgradeCode — уникальный GUID

Чтобы упростить себе жизнь определим некоторые переменные. Для чего — название продукта, например, не раз может встречаться в скрипте, если нам захочется его изменить придется искать его по всему скрипту и менять на новое. Чтобы избежать этого определим переменную, которая будет содержать название продукта и, в случае необходимости, будем менять только ее. Над разделом Product добавим:

<? define ProductName ="SetupProject1" ? >
<? define ProductVersion ="1.0.0.0" ? >
<? define ProductCode ="b7bc7c6f-9a4e-4973-be84-eca8e3427c97" ? >
<? define UpgradeCode ="06a81104-1e30-463d-87e1-e8a79b4c682a" ? >
<? define Manufacturer ="MyCompany" ? >

* This source code was highlighted with Source Code Highlighter .

Теперь заменим значение параметров ключа Product на переменные:

< Product Id ="$(var.ProductCode)" Name ="$(var.ProductName)" Language ="1049" Version ="$(var.ProductVersion)" Manufacturer ="$(var.Manufacturer)" UpgradeCode ="$(var.UpgradeCode)" >

* This source code was highlighted with Source Code Highlighter .

Определимся теперь с тем куда мы будем устанавливать наш продукт.

Ключ Directory — определяет путь для установки.
Directory корневой элемент для всех папок, которые будут использоваться для установки проекта.
Directory папка Program Files (на что указывает
Directory папка с именем SetupProject1 в папке Program Files. Заменим сразу Name=«SetupProject1» на Name="$(var.ProductName)"

Добавим файлы в пакет установки. Для этого сначала добавим устанавливаемые компоненты. Следуя совету «Remove the comments around this Component» уберем комментарии с Component внутри целевой папки и добавим туда, например, калькулятор.

< Component Id ="ProductComponent" Guid ="b11556a2-e066-4393-af5c-9c9210187eb2" >
< File Id ='Calc' DiskId ='1' Source ='C:\WINDOWS\system32\calc.exe' />
</ Component >

* This source code was highlighted with Source Code Highlighter .

< Feature Id ="ProductFeature" Title ="$(var.ProductName)" Level ="1" >
< ComponentRef Id ="ProductComponent" />

</ Feature >

* This source code was highlighted with Source Code Highlighter .

Осталось добавить ярлык в меню Пуск.

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

В раздел Directory где-нибудь в конце добавляем:

< Directory Id ="ProgramMenuFolder" >
< Directory Id ="ApplicationProgramsFolder" Name ="$(var.ProductName)" >
< Component Id ="ApplicationShortcutCalc" Guid ="4CEBD68F-E933-47f9-B02C-A4FC69FDB551" >
< Shortcut Id ="ShortcutCalc"
Name ="Calc"
Description ="$(var.ProductName)"
Target ="[INSTALLLOCATION]Calc.exe"
WorkingDirectory ="INSTALLLOCATION" />

< RemoveFolder Id ="ApplicationProgramsFolder" On ="uninstall" />

< RegistryValue Root ="HKCU" Key ="Software\$(var.Manufacturer)\$(var.ProductName)" Name ="installed" Type ="integer" Value ="1" KeyPath ="yes" />

</ Component >
</ Directory >
</ Directory >

* This source code was highlighted with Source Code Highlighter .

Начинаем разбираться:
Directory — указывает на директорию, в которой содержатся ярлыки меню Пуск.
Directory — папка нашей программы в меню Пуск
Component — компонент, содержащий ярлык (не забыть включить его в Feature)
Shortcut — собственно ярлык к калькулятору

Финальная версия файла должна выглядеть так:

< Wix xmlns ="http://schemas.microsoft.com/wix/2006/wi" >
<? define ProductName ="SetupProject1" ? >
<? define ProductVersion ="1.0.0.0" ? >
<? define ProductCode ="b7bc7c6f-9a4e-4973-be84-eca8e3427c97" ? >
<? define UpgradeCode ="06a81104-1e30-463d-87e1-e8a79b4c682a" ? >
<? define Manufacturer ="MyCompany" ? >

< Product Id ="$(var.ProductCode)" Name ="$(var.ProductName)" Language ="1049" Version ="$(var.ProductVersion)" Manufacturer ="$(var.Manufacturer)" UpgradeCode ="$(var.UpgradeCode)" >
< Package InstallerVersion ="200" Compressed ="yes" />

< Media Id ="1" Cabinet ="media1.cab" EmbedCab ="yes" />

< Directory Id ="TARGETDIR" Name ="SourceDir" >
< Directory Id ="ProgramFilesFolder" >
< Directory Id ="INSTALLLOCATION" Name ="$(var.ProductName)" >
< Component Id ="ProductComponent" Guid ="b11556a2-e066-4393-af5c-9c9210187eb2" >
< File Id ='Calc' DiskId ='1' Source ='C:\WINDOWS\system32\calc.exe' />
</ Component >
</ Directory >
</ Directory >
< Directory Id ="ProgramMenuFolder" >
< Directory Id ="ApplicationProgramsFolder" Name ="$(var.ProductName)" >
< Component Id ="ApplicationShortcutCalc" Guid ="4CEBD68F-E933-47f9-B02C-A4FC69FDB551" >
< Shortcut Id ="ShortcutCalc"
Name ="Calc"
Description ="$(var.ProductName)"
Target ="[INSTALLLOCATION]Calc.exe"
WorkingDirectory ="INSTALLLOCATION" />

< RemoveFolder Id ="ApplicationProgramsFolder" On ="uninstall" />

< RegistryValue Root ="HKCU" Key ="Software\$(var.Manufacturer)\$(var.ProductName)" Name ="installed" Type ="integer" Value ="1" KeyPath ="yes" />

</ Component >
</ Directory >
</ Directory >
</ Directory >

< Feature Id ="ProductFeature" Title ="SetupProject1" Level ="1" >
< ComponentRef Id ="ProductComponent" />

< ComponentRef Id ="ApplicationShortcutCalc" />

</ Feature >

< Property Id ="WIXUI_INSTALLDIR" Value ="INSTALLLOCATION" ></ Property >
< WixVariable Id ="WixUILicenseRtf" Overridable ="yes" Value ="License.rtf" />

< UIRef Id ="WixUI_InstallDir" />

* This source code was highlighted with Source Code Highlighter .

Я создаю небольшое приложение, и я хотел бы создать один файл MSI.

на Visual Studio 2010 у вас есть этот тип проекта в:

Другие Типы Проектов ->установка и развертывание ->установщик Visual studio -> Setup Project

но единственное, что вы получили в Visual Studio 2012 это "включить InstallShield Limited Edition".

Почему его больше нет? И как я могу его вернуть? Есть новый способ сделать это?

чтобы создать проекты установки в Visual Studio 2012 с InstallShield Limited Edition, смотритевидео.

InstallShield limited edition, который не может установить службы.

"остров на сегодняшний день является худшим вариантом установки и обновлен, читать - платная версия громоздка в лучшем случае и невозможна в большинстве положения. InnoSetup, Nullsoft, Advanced, WiX, или почти любой другой установщик лучше. Если вы сделали опрос вы увидим, что никто не использует остров. Я не знаю, почему вы, ребята, продолжаете общаться с InstallShield. Это вредит вашему авторитету. Любой разработчик стоит половина его веса в соли знает, что остров бесполезен и когда вы стоите за этим мы должны подвергнуть сомнению суждение Microsoft."

The Набор Инструментов WiX, который, в то время как мощный более неудобный и имеет крутой кривой обучения. Существует даже загружаемый шаблон для установки служб Windows (ref. VS2012: установщик для служб Windows?).

используйте решение VS2008 / 2010 для создания вашего установщика
переключитесь на другой инструмент, такой как InstallShield или установщик Windows XML

вы пробовали метод "опубликовать"? Вы просто щелкните правой кнопкой мыши на файле проекта в обозревателе решений и выберите команду "опубликовать" в контекстном меню. Это создает установщик в несколько очень простых шагов.

вы можете выполнить дополнительную настройку установщика на вкладке публикация в окне свойств проекта.

NB: этот метод работает только для приложений WPF и Windows Forms.

Microsoft прислушалась к крику о поддержке установщиков (MSI) в Visual Studio и выпустила Расширение Проектов Установщика Visual Studio. Теперь можно создавать установщики в Visual Studio 2013;скачать расширение здесь из visualstudiogallery.

Майкрософт преподнесла загадочный сюрприз — вынесла на суд общественности проект, снабженный лицензией Open Source (точнее, Common Public License). А чтоб выглядеть совсем уж по-свойски, исходники разместили на SourceForge. Посмотрим-посмотрим…

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

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

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

Следующим (после продукта) уровнем детализации является пакет. Он может включать один или несколько файлов — обычно файлы инсталляции 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-документа и имеет вид:

В результате вы получите файл с тем же именем, что и ваш 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 Files\Test Program появится текстовый файл. Удалить приложение можно, как и прежде, через "Панель управления". Дополнительно вы можете проделать то же самое, выполнив команду:

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

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

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

Читайте также: