Сообщений 5 
Оценка 250
[+1/-0]
Оценить 
| Сообщений 5 Оценка 250
[+1/-0]
Оценить
|
За основу документа был взят WiX FAQ от Люка Стивенса (Luke Stevens). При переводе акцент был сделан НЕ на точности передачи авторского стиля, а на смысле. Ряд вопросов пришлось обновить и дополнить. Кроме того, был добавлен новый раздел «Локализация».
Windows Installer XML (WiX) — это набор инструментов с открытым исходным кодом, позволяющих собирать из XML-описаний пакеты формата Windows Installer.
WiX - первый продуктом компании Microsoft, который стал развиваться на площадке SourceForge и распространяться под открытой лицензией CPL (двумя другими позже стали Windows Template Library и FlexWiki).
В состав WiX входит ряд консольных утилит:
Релизы WiX размещены на SourceForge: WiX 2.0 + Votive2, WiX 3.0 + Votive 3. Кроме того, разработчики WiX придерживаются практики еженедельных релизов.
ДА! Вам нужно лишь подписать соглашение, после чего вы можете вносить улучшения и отсылать правки на wix-devs@sourceforge.net.
Прежде всего, установите .NET Framework 1.1 и SP1 для него. Инструменты WiX работают под .NET, а без SP1 вы можете столкнуться со случайными ошибками при парсинге больших XML-файлов. .NET Framework требуется только для работы утилит WiX; готовый установочный пакет не требует присутстувия .NET на целевой машине.
При установке, WiX не требует особых настроек — достаточно развернуть .zip-архив в какую-либо папку.
Для того, чтобы при редактировании .wix-файлов в Visual Studio работал IntelliSense, нужно поместить XML-схемы WiX (wix.xsd, wixloc.xsd) в соответствующую папку:
Именно для этого и был разработан Votive.
Votive — это расширение (Add-In) для Visual Studio. Он позволяет создавать «WiX-проекты», которые можно включать в solution и которые действуют точно так же, как и любые другие типы проектов. Все инструменты WiX включены в состав Votive, поэтому для работы с ним не требуется устанавливать WiX отдельно — это может понадобиться уже только для автоматической сборки установщика.
Существует ряд проектов, предоставляющих возможность WYSIWYG-редактирования экранов установщика:
Значения GUID используются WiX в качестве идентификаторов различных объектов, таких как продукт (Product) или компонент (Component), и WiX предполагает, что вы сами выберете нужные значения и укажите их в XML-файле. Для генерации значений вы можете использовать утилиты, такие как uuidgen или guidgen (из VS — команда Tools | Create GUID), но убедитесь, что используется верхний регистр символов и значение не окружено фигурными скобками.
При работе в Visual Studio можно использовать простой макрос, на который можно назначить комбинацию клавиш, либо использовать GUIDGen.NET.
Укажите в свойстве ARPPRODUCTICON идентификатор нужной иконки. Например:
<Property Id="ARPPRODUCTICON" Value="MyProduct.ico" /> <Icon Id="MyProduct.ico" src="C:\MyProduct.ico" /> |
По идее, такой возможности нет.
Разработчик должен принять обдуманное и неизменное решение о том, какие в точности файлы должны быть включены в какой компонент. Если GUID или содержание компонента изменились, то нарушаются правила компонентов, и Windows Installer уже не сможет корректно координировать разделение общих компонентов между несколькими продуктами. Автоматическое добавление всех файлов заданной директории в какой-либо компонент в ходе каждой сборки сделает невозможным сохранение неизменного содержания компонента при изменении содержимого директории.
Утилита tallow позволяет просканировать директорию и сгенерировать компоненты для всех найденных файлов, но полученный в результате исходный код предполагается использовать только в качестве начального варианта для последующей ручной доводки, но не в качестве входа для процесса автоматической сборки — все что подходит для автоматической сборки должно передаваться в candle, но никак не в tallow.
Существует инструмент mallow, позволяющий автоматически собирать список файлов в директории и поддиректориях, и генерирующий также компоненты и тэги Directory, что позволяет подключать полученный файл так, что все поддерево директорий и файлы будут включены в пакет установки и установлены в виде такого же поддерева в заданную папку.
Рекомендуемый способ состоит в том, чтобы собрать всю регистрационную информацию и включить ее в компонент (тэг Component) для этой DLL в виде тэгов TypeLib, Class, Interface, ProgID итд., и, как последнее средство — тэг Registry. В качестве начального материала вы можете использовать результат работы утилиты tallow (либо улучшенной tallow, либо wixtlib для библиотек типов). Например:
<Component Id="SomeFile" Guid="..." DiskId="1"> <File Id="SomeFile.dll" Name="SomeFile.dll" KeyPath="yes" /> <TypeLib Id="..." Advertise="yes" MajorVersion="1" MinorVersion="0" Language="0" Description="SomeFile 1.0 Type Library" Cost="50000"> <Class Id="..." Advertise="yes" Description="SomeClass Class" Context="InprocServer32" ThreadingModel="both"> <ProgId Id="SomeFile.SomeClass.1" Description="SomeClass Class"> <ProgId Id="SomeFile.SomeClass" Description="SomeClass Class" /> </ProgId> </Class> </TypeLib> </Component> |
Если для DLL требуется само-регистрация, укажите в тэге File атрибут SelfRegCost:
<File Id="SomeFile.dll" Name="SomeFile.dll" KeyPath="yes" SelfRegCost="50000" /> |
Но имейте в виду, что использование саморегистрации крайне неодобряется, поскольку она подрывает возможность Windows Installer управлять установкой регистрационной информации.
Установите для тэга File атрибуты Assembly и AssemblyManifest, но не указывайте атрибут AssemblyApplication. Например:
<Component Id="SomeFile" Guid="..." DiskId="1"> <File Id="SomeFile.dll" Name="SomeFile.dll" KeyPath="yes" src="C:\SomeFile.dll" Checksum="yes" Assembly=".net" AssemblyManifest="SomeFile.dll" /> </Component> |
Такая сборка не будет устанавливаться до фазы «commit», поэтому до этого ее невозможно будет использовать в custom actions.
Если вы передумаете и решите не включать сборку в GAC, установите атрибут AssemblyApplication в то же значение что и атрибут AssemblyManifest.
Основная идея состоит в том чтобы проверять свойство, которое устанавливается по-разному в зависимости от наличия компонента и его версии. Вы можете создать условие запуска установки, поместив тэг Condition внутри Product, например:
<Condition Message="Для установки требуется Windows XP или выше.">
<![CDATA[VersionNT >= 501]]>
</Condition>
|
Для проверки версии ОС вы можете использовать предопределенные свойства — такие как VersionNT или Version9X, для проверки версии .NET Framework — MsiNetAssemblySupport.
Для поиска компонента, установленного из MSI, можно использовать поиск по GUID тэгом ComponentSearch. Для компонента Windows, такого как IIS, может понадобиться поиск по реестру, например:
<Property Id="W3SVCMAJORVERSION"> <RegistrySearch Id="W3SVCMAJORVERSION" Type="registry" Root="HKLM" Key="System\CurrentControlSet\Services\W3SVC\Parameters" Name="MajorVersion" /> </Property> |
— этот код под Windows Server 2003 установит свойство W3SVCMAJORVERSION в значение «#6», если сервис «IIS web publishing» установлен, либо в пустое значение, если не установлен.
Проблема установки и обновления системных компонентов (prerequisites), таких как .NET Framework, MDAC, MSDE и др., решается использованием программы-bootstrapper, задача которой — установить и обновить все нужные компоненты, после чего запустить на выполнение ваш .MSI-пакет.
Существует несколько таких программ:
Есть три важных GUID, которые определяют ваш установочный пакет, и которые особенно важны для обновлений продукта:
Хотя функциональность Windows Installer можно расширять только с помощью действий (custom actions, CA), функциональность WiX по созданию установочных пакетов можно увеличить за счет расширений. WiX может использовать расширения в виде внешних DLL, определяющих дополнения к схеме, заполняющих пользовательские таблицы итп. Читайте об этом здесь.
Под руководством Gabor DEAK JAHN существует т.н. WiX Localization Project, объединяющий усилия по написанию файлов локализации (.wxl-файлов) для всех основных языков. В дистрибутив последних версий WiX входит 4 языковых файла (для en-US, de-DE, es-ES и nl-NL), хотя еще 9 языковых файлов (в т.ч. и ru-RU) числятся в списке как завершенные.
За основу локализации берется файл WixUI_en-us.wxl, основная часть сообщений относится к Windows Installer, их перевод основывается на файле Intl.zip из MSI SDK. Перевод остальных сообщений выполняется непосредственно с англоязычного файла.
«Неофициальный» файл локализации WixUI_ru-ru.wxl можно взять здесь.
Во-первых, проверьте что кодировка файла совпадает с кодировкой, объявленной в начале этого файла, например:
<?xml version="1.0" encoding="windows-1251" ?> |
Затем, проверьте что корректно проставлены атрибуты Codepage и Language тэга Product, а также атрибут SummaryCodepage тэга Package, например:
<?xml version="1.0" encoding="windows-1251" ?> <Wix xmlns="http://schemas.microsoft.com/wix/2003/01/wi"> <Product Id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" Name="Мой продукт" Version="x.x.x.x" Manufacturer="Моя компания" Language="1049" Codepage="1251"> <Package Id="????????-????-????-????-????????????" Description="Описание пакета" Comments="Комментарий к пакету" Compressed="yes" InstallerVersion="200" SummaryCodepage="1251"/> |
Стоит начать с анализа лога установки, который можно получить, запустив установку командой:
msiexec /i MyInstaller.msi /l*v MyInstaller.log |
Для деинсталляции используем:
msiexec /x MyInstaller.msi /l*v MyInstaller.log |
Если при запуске вы получаете сообщение вида:
The application failed to initialize properly (0xc0000135). |
то обычно это означает, что вы не установили .NET Framework 1.1, который требуется для работы WiX.
По умолчанию, политика безопасности .NET Framework предотвращает попытки запуска кода, загруженного с потенциально небезопасных источников. Вы можете изменить эту политику с помощью утилиты CasPol:
%WINDIR%\Microsoft.NET\Framework\v1.1.4322\CasPol -q -ag All_Code -strong -file "C:\Program Files\WiX\wix.dll" -noname -noversion FullTrust -name "WiX_Strong_Name" -levelfinal on |
где C:\Program Files\WiX заменяется на путь к любой копии wix.dll.
Вероятно, вы забыли назначить GUID-ы компонентам. Если для компонента не указан GUID, то Windows Installer установит его, но не будет отслеживать его или деинсталлировать его.
Если дело не в этом, то скорее всего проблема в том, что вы деинсталлируете не то же самое что было установлено, поскольку вы опираетесь на имя базы данных или виртуального каталога или что-то еще, что определено в свойстве, но это свойство изменилось, потому что…
Windows Installer не сохраняет значения свойств между сессиями. Если в ходе установки интерфейс запрашивает у пользователя значение свойства, и оно требуется вам на этапе поддержки или деинсталляции, то только от вас зависит, сохраняете вы его где-либо или нет. Обычно, значение свойства просто сохраняется в каком-либо ключе реестра, а в последующих сессиях значение свойства восстанавливается с использованием поиска по реестру.
По умолчанию, запланированное действие (scheduled custom action) выполняется всякий раз при запуске пакета, вне зависимости от того, происходит ли установка, деинсталляция, модификация, восстановление, что бы то ни было. Если вы хотите, чтобы действие выполнялось только в одном из этих случаев, используйте условие, такое как «NOT Installed» или «&MyFeature > 2».
Есть множество возможных причин. Если права пользователя достаточны, то наиболее вероятная проблема состоит в том что путь к исполняемому файлу задан неверно, что может случиться, если вы забыли задать KeyPath для компонента, содержащего сервис.
| Сообщений 5 Оценка 250
[+1/-0]
Оценить
|