• Главная
• В избранное
• Наш E-MAIL
• Добавить материал
• Нашёл ошибку
• Вниз

Итак, что же представляет собой пакет инсталляции для Windows Installer? Обычно инсталляционные пакеты хранятся в файлах с расширением .msi и представляют собой реляционную базу данных, хранящую всю логику и данные, необходимые для правильной установки программного продукта. А доступом к этим данным управляет непосредственно Windows Installer. То есть, как и любая другая база данных, пакет инсталляции состоит из множества связанных друг с другом таблиц. Так как база данных является реляционной, таблицы связываются с помощью первичных и внешних ключей. Это обеспечивает эффективный способ управления процессом инсталляции и позволяет пользователям с легкостью приспосабливать сложное приложение или даже группу приложений к своим нуждам. Таблицы базы данных отражают общую схему приложения, включающую:

• доступные опции приложения;

• компоненты;

• связи между опциями и компонентами;

• необходимые записи в реестре Windows;

• пользовательский интерфейс приложения. Для создания базы данных необходимо заполнить таблицы данными о приложении и о процессе инсталляции. Это можно сделать вручную, используя утилиту ORCA, поставляемую фирмой Microsoft в составе Windows Installer SDK. Кстати, эта утилита может очень помочь в изучении структуры базы данных пакета инсталляции. Но заполнение таблиц вручную - достаточно трудоемкий процесс даже для инсталляций умеренного размера. И это неудивительно, если учесть, что база данных любого пакета инсталляции включает как минимум 87 таблиц!

ПРИМЕЧАНИЕ Справедливости ради надо сказать, что реально инсталлятор обычно использует только порядка 30-35 из них.

Поэтому гораздо проще и удобнее использовать пакеты для создания инсталляторов. К ним относятся, например Visual Studio Installer, Wise Installer, InstallShield Developer и некоторые другие, не столь широко известные пакеты. Кстати, многие пакеты создания инсталляторов включают в базу данных свои дополнительные таблицы, например, в пакетах, созданных с помощью InstallShield Developer количество таблиц достигает 113! При этом никто не запрещает нам, как разработчикам, определять и добавлять свои таблицы, дополняя тем самым модель данных Windows Installer.

ПРИМЕЧАНИЕ Вышесказанное справедливо для Windows Installer версии 2.0, который позволяет распространять и устанавливать приложения для новой перспективной платформы Microsoft -.NET Framework.

Я не буду приводить полный список этих таблиц, так как он займет слишком много места. Вместо этого выделим основные группы таблиц и рассмотрим их подробнее.

В базе данных пакета инсталляции можно выделить семь основных групп:

• базовые таблицы;

• файловые таблицы;

• таблицы записей в реестре Windows;

• системные таблицы;

• таблицы поиска;

• таблицы информации о программе;

• таблицы процесса инсталляции;

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

Рисунок 1. Структура группы Базовые таблицы

ПРИМЕЧАНИЕ На этой и на последующих диаграммах черный круг, соединенный с белым ромбом обозначает отношение один-ко-многим между первичным ключом в первой таблице и внешним ключом во второй.

Таким образом, мы видим, что эта группа состоит из 11 связанных таблиц. Ниже приведены их краткие описания:

ПРИМЕЧАНИЕ

1. Если в таблице Condition нет условия для функции из таблицы Feature - это значит, что функция будет установлена в любом случае.

2. Один компонент может быть связан с несколькими функциями. В данном случае под термином значительное обновление понимается обновление, приводящее к изменению свойства ProductCode.

3. Я не буду останавливаться на обновлениях, так как эта тема заслуживает отдельной статьи.

Эта группа таблиц содержит информацию обо всех файлах, составляющих программный продукт. Большая часть этих файлов перечислена в таблице File. Таблица Directory не входит в эту группу, но, тем не менее, очень тесно связана с ней, так как отражает структуру каталогов приложения. При разработке инсталляционного пакета эта группа таблиц должна заполняться после того, как приложение разбито по функциям и компонентам и заполнена группа Базовых таблиц.

ПРИМЕЧАНИЕ Такие пакеты как InstallShield Developer и Wise Installer позволяют не придерживаться такого жесткого порядка заполнения таблиц. Но рекомендуется все-таки тщательно продумать структуру пакета инсталляции перед тем, как начать заполнять базу данных.

Структура этой группы показана на рисунке 2.

Рисунок 2. Структура группы Файловые таблицы

Эта группа состоит из 15 таблиц. Их краткое описание дано ниже.

ПРИМЕЧАНИЕ

1. Для получения более подробной информации о привязках смотрите описание функции Windows API BindImageEx

2. В операционных системах Windows95/98 в этой таблице также хранится список изменений в файле autoexec.bat

3. Таблица Icon используется при публикации программных продуктов

4. Таблица MsiFileHash может использоваться только для файлов, не содержащих информации о версиях. Windows Installer может использовать информацию из этой таблицы, чтобы не выполнять лишнее копирование файлов, уже содержащихся на пользовательском компьютере и совпадающих с файлами из пакета инсталляции.

Эта группа содержит таблицы, описывающие различные виды информации в реестре Windows. Структура группы показана на рисунке 3.

Рисунок 3. Структура группы таблиц Записи в реестре Windows.

Внимательный читатель, конечно же, заметил, что на рисунке присутствуют таблицы из других групп, такие, как Component, Feature и File. Эти таблицы включены сюда для того, чтобы более ясно показать логику работы этой группы. Кроме того, здесь присутствуют таблицы, уже упоминавшиеся в других группах, но здесь играющие немного другую роль (это таблицы SelfReg и Environment).

Таким образом, эта группа включает 11 таблиц, краткое описание которых дано ниже:

ПРИМЕЧАНИЕ

1. При публикации приложения никаких записей о библиотеках типов не делается. Запись производится только в момент установки компонента, связанного с библиотекой.

2. Использование саморегистрации в Windows Installer НЕ РЕКОМЕНДУЕТСЯ и включено только для обеспечения обратной совместимости с предыдущими технологиями установки программ. Вместо этого рекомендуется заполнить соответствующие таблицы нужной информацией, аналогичной той, что прописывает нужный модуль при вызове его функции DllRegisterServer.

3. Эта таблица включена в данную группу, так как в операционных системах Windows NT / 2000 / XP данные из нее пишутся в реестр.

СОВЕТ При заполнении этой группы нужно попытаться сделать таблицу Registry как можно компактней, поместив как можно больше информации в другие, более специфичные таблицы. Это делается, потому что Installer не может выделить различные типы реестровых записей в таблице Registry и, следовательно, не может использовать внутреннюю логику для задействования всех своих возможностей, например - публикации или установки по требованию. Кроме того, такой способ организации данных поможет уменьшить риск записи лишней информации о COM-серверах.

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

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

Итак, эта группа состоит из 5 таблиц, краткое описание которых дано ниже:

Таблицы поиска используются для поиска файлов и приложений на компьютере пользователя. Чтобы найти файл, нужно сначала задать сигнатуру файла, а затем произвести поиск. Таблицы этой группы можно использовать для поиска в реестре, в данных конфигурации инсталлятора, по дереву каталогов или в .ini-файлах. При этом ищется файл или каталог с заданной уникальной сигнатурой. Затем, если файл найден, его сигнатура проверяется по таблице Signature, чтобы убедиться, что данный файл действительно тот, который нужен, а не просто еще один файл с таким же именем. Если запись в таблице поиска не связана с таблицей Signature, значит, запись ссылается на каталог, а не на файл.

Компонент, которому принадлежит нужный файл, определяется через связь между таблицами File и Component. Installer определяет подчиненность файла через таблицу компонентов, потому что каждый файл связан с одним компонентом. Местоположение компонента определяется по внешнему ключу в таблице Component, указывающему на таблицу Directory.

Нужные приложения ищутся аналогично: при этом находятся определенные файлы, из которых состоит приложение. Installer также предоставляет две таблицы, позволяющие искать предыдущие версии приложений: AppSearch и CCPSearch.

Группа таблиц поиска состоит из 7 таблиц, описание которых дано ниже:

ПРИМЕЧАНИЕ

1. Формально по документации Microsoft таблица Signature не относится к группе таблиц поиска. Но так как она нигде, кроме поиска, не используется, я позволил себе внести ее в эту группу.

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

Состоит эта группа из пяти таблиц:

ПРИМЕЧАНИЕ

1. Свойство - это глобальная переменная, которая используется Microsoft Windows Installer во время инсталляции.

Таблицы этой группы управляют выполнением стандартных и пользовательских операций.

ПРИМЕЧАНИЕ Тема операций в Windows Installer обширна и ей будет посвящена одна из следующих статей.

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

ПРИМЕЧАНИЕ

1. Все операции в последовательности инсталляции, вплоть до InstallValidate и диалогов выхода, помещаются в таблицу InstallUISequence. Все операции от InstallValidate и до конца инсталляции - в таблицу InstallExecuteSequence. Так как последняя таблица может использоваться независимо от первой (например, если пользовательский интерфейс отключен), она включает все операции инициализации, такие как LaunchConditions, CostInitialize, CostFinalize и ExecuteAction.

2. Все пользовательские операции, выполняемые в этой последовательности, при необходимости использования пользовательского интерфейса должны пользоваться функцией API MsiProcessMessage, вместо диалогов из таблицы Dialog.

3. Все операции в последовательности инсталляции, вплоть до InstallValidate и диалогов выхода, помещаются в таблицу AdminUISequence. Все операции от InstallValidate и до конца инсталляции - в таблицу AdminExecuteSequence. Так как последняя таблица может использоваться независимо от первой (например, если пользовательский интерфейс отключен), она включает все операции инициализации, такие как LaunchConditions, CostInitialize, CostFinalize и ExecuteAction.

4. Таблица AdvtExecuteSequence может содержать только ограниченный набор стандартных операций. Пользовательские операции не должны содержаться в этой таблице.

К другой группе относятся таблицы, позволяющие расширять функциональность пакета инсталляции. Достаточно часто, особенно при установке сложных программных продуктов, встроенной функциональности Windows Installer, основанной на стандартных операциях, не хватает. Здесь и приходит на помощь таблица Custom Action, позволяющая создавать и хранить в инсталляционной базе данных информацию для выполнения пользовательских операций.

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

Следующая группа таблиц расширяет возможности инсталлятора по манипулированию файлами и каталогами в процессе инсталляции.

ПРИМЕЧАНИЕ

1. Хотя Installer и создает при инсталляции каталоги по мере необходимости, они удаляются, если не содержат файлов. Каталоги, перечисленные в таблице CreateFolder, не удаляются до тех пор, пока не будет удален связанный с ними компонент.

И, наконец, последняя в списке, но далеко не последняя по значимости таблица, управляющая выполнением инсталляции: LaunchCondition. Эта таблица содержит список условий, при выполнении которых может начаться процесс инсталляции. Следует заметить, что эта таблица управляет процессом в целом и для успешного запуска процесса инсталляции необходимо выполнение ВСЕХ содержащихся в ней условий.

Список таблиц, используемых Windows Installer, весьма велик. И вполне естественно, что в рамках статьи невозможно рассмотреть все из них. Многие из таблиц, не упоминавшихся здесь, будут рассмотрены в следующих статьях, при рассмотрении более узких тем.