Windows Installer

Windows Installer (установщик Windows) — подсистема Microsoft Windows, обеспечивающая установку программ (инсталлятор). Является компонентом Windows, начиная с Windows 2000; может доустанавливаться и на более ранние версии Windows. Вся необходимая для установки информация (иногда и вместе с устанавливаемыми файлами) содержится в установочных пакетах (installation packages), имеющих расширение .msi.

Содержание

История

Windows Installer был разработан в 1995—1998 годах и имел вначале кодовое название Darwin. Ранние версии назывались Microsoft Installer, отсюда стандартное расширение файла инсталляционного пакета — .msi. [1]

Первая версия Installer’а вышла в начале 1999 в качестве инсталлятора Microsoft Office 2000. В конце того же года Installer стал частью Windows 2000. Майкрософт всячески поощрял переход разработчиков на новый инсталлятор, включив в список требований к программам, желающим получить так называемый знак Windows 2000 Logo, требование устанавливаться с помощью Windows Installer.

Windows Installer оказался значительным шагом вперёд по отношению к предыдущему инсталлятору Microsoft — Setup API (ACME Setup): в нём были введены возможности GUI, поддержка деинсталляции и отката в любой момент установки (включая откат во время деинсталляции), корректная работа с правами доступа в Windows и другие возможности, что сделало его сильной альтернативой различным существовавшим на рынке инсталляционным пакетам.

Логическая структура пакета

Компонента (component) — минимальная неделимая установочная единица, представляющая собой группу файлов, значений реестра, создаваемых папок и других элементов, объединённых общим именем (именем компоненты) и либо устанавливаемых вместе, либо не устанавливаемых. Компоненты скрыты от конечного пользователя. Каждая компонента имеет ключевой путь (key path) — например, имя своего главного файла — по которому определяется наличие этой компоненты на компьютере пользователя.

Возможность (feature; в русифицированной версии Windows именно это слово переводится как «компонента», что вносит путаницу) — это иерархическая группа компонент и/или других возможностей. Когда при установке показывается диалог выбора устанавливаемых частей программы, пользователь управляет выбором именно возможностей. Выбор возможности для установки влечёт за собой установку всех компонент, которые в неё включены.

Физическая структура пакета

Файл .msi представляет собой составной документ OLE (OLE compound document — в том же формате-контейнере хранятся документы Microsoft Word, Excel и т. д.), в котором содержится небольшая реляционная база данных — набор из нескольких десятков взаимосвязанных таблиц, содержащих различную информацию о продукте и процессе установки. При этом все строковые данные в базе хранятся вместе в отдельном потоке документа, а в таблицах базы на них имеются ссылки; таким образом избегают дублирования строк, что значительно уменьшает размер базы.

Процесс установки

Процесс установки состоит из нескольких этапов — сбора информации, выполнения (собственно установки), а также, возможно, отката (в случае ошибки или отмены установки пользователем).

Действия

Каждый этап установки состоит из последовательности действий (actions), записанной в базе данных. Действиям присвоены номера, определяющие порядок их выполнения, а иногда — и условия, при которых действия выполняются или не выполняются.

Большая часть действий — это стандартные действия, характерные для типичного процесса сбора информации и установки. Все эти действия документированы. Кроме них, пользователь может определить и свои дейстия (custom actions).

Действия, определённые пользователем, могут быть либо написаны на одном из скриптовых языков, встроенных в операционную систему (VBScript), либо размещаться в специально созданной C, C++ и т. д.). Файлы с этими действиями помещаются внутрь файла .msi и извлекаются оттуда в начале запуска инсталляции.

Сбор информации

На этапе сбора информации Windows Installer собирает инструкции (либо путём взаимодействия с пользователем, либо программным путём) установить или удалить одну или несколько возможностей, входящих в продукт. Эти инструкции в дальнейшем формируют на основе базы данных внутренний сценарий, детально описывающий последующий этап выполнения.

Этот этап называют также непосредственным режимом (immediate mode).

Выполнение

К началу этого этапа инсталлятор генерирует внутренний сценарий, предназначенный для выполнения без вмешательства пользователя. Этот сценарий выполняется инсталлятором в привилегированном режиме службы NT (конкретно — под аккаунтом LocalSystem). Привилегированный режим требуется из-за того, что инсталляция могла быть запущена пользователем, не обладающим необходимыми правами для изменения системных параметров и файлов (хотя право установить программу ему было предоставлено).

Этот этап иногда называется отложенным режимом (deferred mode).

Откат

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

С чего начать изучение Windows Installer?

Технология Windows Installer (MSI) является стандартом де-факто в мире системных администраторов, занимающихся распространением и поддержкой программного обеспечения для десктопных и серверных версий Windows. Формат MSI поддерживается всеми крупнейшими системами управления конфигурациями (Microsoft SCCM, CA Unicenter и многими другими), а для некоторых систем распространения ПО — является единственным поддерживаемым форматом.
Мой опыт работы с этой технологией — как теоретический, так и практический — приобретен за время работы в компании «Инфопульс Украина» и связан с созданием MSI-пакетов и подготовкой готовых MSI-пакетов к автоматической установке в корпоративной среде.

Зачем это вам?

Если вы занимаетесь централизованной установкой приложений в сетях Windows, знание формата MSI и умение создавать и редактировать пакеты в этом формате вам может здорово пригодиться при подготовке пакета к развертыванию и диагностике проблем. В Европе и США технология Windows Installer востребована многими крупными заказчиками, поэтому знание MSI может быть плюсом для системного администратора при трудоустройстве.

Что нужно знать и уметь перед началом изучения?

Ничего сложного. Если у вас есть опыт администрирования и поддержки небольшой (а лучше большой, иерархической) сети Windows-машин, вероятнее всего вы уже сталкивались с основными вопросами и понятиями, которые вам понадобятся. Перед тем, как начать, убедитесь, что вы хорошо понимаете структуру файловой системы Windows, структуру профиля пользователя и структуру реестра, знаете что такое процессы и службы в Windows, умеете управлять учетными записями пользователей и знаете где находятся журналы событий. Для того, чтобы научиться создавать пакеты MSI, вам совсем необязательно иметь опыт разработчика, хотя конечно лучше если такой опыт у вас есть. И совсем не обязательно уметь писать запросы на SQL, хотя это тоже может пригодиться (ведь каждый MSI-файл — это небольшая реляционная база данных). Но обязательно нужно уметь читать и понимать техническую документацию на английском, без этого скорее всего ничего не получится. При изучении теории (и при создании пакетов на практике) постарайтесь хотя бы на первых порах строго следовать стандартам Windows Installer, избегая вспомогательных утилит типа InstallShield/InstallScript, так вы лучше поймёте как правильно создать MSI-пакет.

Готовим песочницу и начинаем практику

Начать нужно с установки и настройки виртуальной машины. В процессе обучения вам придется немало поэкспериментировать, поэтому лучше сделать это в песочнице. Если нужны бесплатные продукты — устанавливаем VirtualBox или VMWare Player (для профессиональных задач их функционала может быть недостаточно, но для обучения — вполне подойдет). В виртуальной машине, естественно, нужно установить Windows на ваш выбор (XP и выше).
Если у вас уже есть опыт работы с утилитами от Sysinternals — прекрасно. Если нет — самое время восполнить пробел. Нам понадобятся минимум две: для отслеживания файловой и реестровой активности приложения при установке или во время его работы — Process Monitor, для запуска инсталляции от имени учетной записи LocalSystem — PsExec. Попрактикуйтесь использовать эти утилиты на простом приложении типа notepad (с какими ресурсами работает notepad при открытии файла, при сохранении файла; запустите notepad от имени пользователя LocalSystem, поэкспериментируйте с сохранением файлов и установкой файловых ассоциаций), в дальнейшем эти навыки пригодятся.

Установите Panda QuickShot или другой софт для сравнения состояний системы. Разберитесь с основным функционалом, научитесь отслеживать файловые и реестровые изменения в системе при установке нового приложения или изменении параметров системы (самое простое — зарегистрируйте новую файловую ассоциацию для notepad, измените обои рабочего стола и отследите где хранятся эти настройки). Подойдите к этому творчески, поле для экспериментов обширное.

Скачайте MSI-инсталлятор какого-нибудь несложного приложения (например, Orca, InstEd или Firefox). Установите пакет на виртуальной машине, с помощью описанных выше утилит изучите устанавливаемые им ресурсы. Научитесь пользоваться командной строкой Windows Installer (msiexec /?), поэкспериментируйте с различными опциями установки и сравните результат. Выполните удаление приложения из командной строки, установите пакет в автоматическом (silent) режиме.
Установите InstEd или Orca на хост-машине. Откройте MSI-пакет, который вы устанавливали на виртуальной машине, с помощью одной из этих утилит. Сравните записи основных таблиц в MSI-пакете (File, Directory, Registry) с ресурсами (файлы, папки, ключи реестра), установленными этим пакетом на вашей виртуальной машине (результат сравнения снимков состояний с помощью Panda QuickShot).

Немного теории

Теперь самое время взяться за теорию. Не буду дублировать официальную документацию и отдельные полезные статьи по ссылкам ниже, просто попробую перечислить вещи, с которыми нужно разобраться для начала:

• Таблица Property, код продукта (ProductCode), код пакета (PackageCode), стандартные свойства в MSI;
• Таблица Upgrade и код обновления (UpgradeCode);
• Таблицы Feature, Component и их назначение;
• Таблицы Directory, File, Registry, Shortcut;
• Способы хранения файлов приложения, поставляемых с MSI-пакетом, таблица Media;
• Трансформы, их создание и применение из командной строки.

Прочтение документации по указанным темам подкрепляйте экспериментами на готовых пакетах, а со временем можно попробовать сделать пакет самому. Этих знаний вам будет достаточно для внесения небольших изменений в MSI-пакеты при подготовке к развертыванию в корпоративной среде (типовые задачи — задание свойств пакета, правка реестра, удаление файлов и ярлыков, отключение кнопки Remove для приложения в Add/Remove Programs). Только не забывайте после внесения любых правок в пакет выполнять тщательное тестирование перед запуском пакета в промышленную эксплуатацию. При тестировании обязательно используйте рекомендации, приведенные в этой статье.
Думаю, на этом пока можно закончить вводную часть. В дальнейшем (если будет интерес) я попробую рассказать об особенностях некоторых готовых MSI-пакетов, предоставляемых производителями ПО для развертывания в корпоративной среде и рассмотреть другие интересующие системных администраторов вопросы.
Пожелания, замечания, а также предложения по темам для следующих статей приветствуются.

Обзор утилит и документации

Бесплатно можно использовать простые редакторы MSI-файлов с ограниченным функционалом — здесь упоминания заслуживают классическая Orca от Microsoft и довольно удобный InstEd. Эти редакторы позволяют вносить небольшие изменения в готовые MSI-файлы, создавать и применять трансформы, но создавать в них MSI-пакеты с нуля довольно непросто (а для больших пакетов — и вовсе не имеет смысла). Но если вы действительно хотите изучить технологию MSI, вам просто необходимо собрать пару простых пакетов в InstEd или Orca и выполнить их валидацию на соответствие стандарту Windows Installer.
Специализированные утилиты для выполнения setup capture (создания или конвертирования установочных пакетов из так называемых «старых форматов»» в формат MSI с использованием сравнения «снимков» системы до и после установки приложения или мониторинга изменений в системе «на лету») — бесплатный AppDeploy Repackager, или более серьезный MSI Generator. MSI-пакетам, созданным с использованием этих утилит, может потребоваться некоторая доработка, которую можно выполнить с помощью редактора MSI.
Серьёзные полнофункциональные (и весьма дорогие) IDE, обеспечивающие поддержку полного цикла работ с MSI-пакетами — если вы будете заниматься технологией MSI профессионально, вам скорее всего не обойтись без этих программ. В этом сегменте до недавнего времени доминировали два продукта — AdminStudio от Flexera и Wise Package Studio от Symantec, но недавно Symantec объявил о прекращении работ по развитию Wise Package Studio, и рынок переходит в руки Flexera. Кроме работы с MSI, AdminStudio позволяет работать с виртуальными пакетами форматов Microsoft App-V, VMware Thin App и Citrix XenApp. Для ознакомительных целей доступна пробная 21-дневная версия.
Отдельно стоит упомянуть WIX (Windows Installer XML) — набор утилит для создания MSI-файлов из XML-описаний. Этот проект был выпущен «Майкрософтом» под открытой лицензией Common Public License, поддерживает интерфейс командной строки и может использоваться для автоматизации создания версий инсталляционных пакетов. Хорошее описание есть на Хабре.

Технология Windows Installer. Обзор возможностей

Источник: rsdn.ru

Предисловие

Данной статьей я начинаю цикл статей, посвященных технологии Windows Installer от Microsoft. Эта статья носит по большей части обзорный характер. В процессе изучения темы я обнаружил, что найти нужную информацию на русском языке практически невозможно. Более того, и на английском языке, за исключением первоисточников в MSDN, очень мало полезной информации. Скромно надеюсь, что данный цикл статей исправит этот пробел.

Технология Windows Installer возникла не на пустом месте, поэтому, прежде чем погрузиться в ее изучение, оглянемся назад лет на 10-15.

Немного истории

\»Золотые\» времена DOS

Если мы вернемся в \»золотые\» времена DOS, то обнаружим, что в то время каждая фирма-поставщик программного обеспечения извращалась по-своему. Не было никакого общего интерфейса пользователя, никаких унифицированных приемов работы с ПО (я не рассматриваю счастливых владельцев компьютеров от фирмы Apple с единым уже в то время пользовательским интерфейсом). Поэтому неудивительно, что не было и единой технологии инсталляции программных продуктов.

Время шло – появилась первая версия Windows (на мой взгляд – просто интересная игрушка), за ней – вторая. Миру ПК попытались дать унифицированный пользовательский интерфейс (пока неудачно), но с точки зрения технологии инсталляции ничего не изменилось: каждый производитель ПО продолжал удивлять нас разнообразными несовместимыми друг с другом инсталляторами.

Ситуация немного начала меняться к лучшему с выходом Windows 3.0, которая наконец-то стала стандартом де-факто пользовательского интерфейса для ПК. Но… с точки зрения инсталляции ничего не изменилось. По-прежнему не было единой базы программ, установленных на компьютере, и не было никакого API для создания унифицированных, совместимых друг с другом и, самое главное, надежных программ инсталляции.

Поэтому вполне естественно, что отсутствие интегрированного решения от поставщика операционной системы позволило занять эту нишу сторонним компаниям-разработчикам. Наиболее известные из них – InstallShield Software и WiseSolutions. Эти компании принесли унифицированный интерфейс в мир программ-инсталляторов и сыграли немалую роль в формировании у пользователей представления о том, как должна выглядеть и вести себя программа инсталляции сложного программного продукта.

Windows 95

И вот в 1995 году вышла совершенно новая версия Windows (по утверждению Microsoft, многие авторитетные источники считают, что действительно новой была версия Windows со скромным номером 3.11, а Windows 95 всего лишь принесла новый пользовательский интерфейс). В этой версии Windows появилось важное новшество: единая база установленных программ.

Но, кроме хранения списка установленных программ и возможности запуска внешних программ инсталляции, эта версия Windows ничего больше не предложила. В результате осталась нерешенной проблема с различными версиями библиотек динамической компоновки (далее по тексту — DLL), с переписыванием системных DLL и т.д.

Следующие версии Windows не принесли ничего нового, немногим лучше оставалась ситуация и в WindowsNT. Технология Setup API, унаследованная еще от Windows 3.x, была очень ограниченной и использовалась (впрочем, используется и сейчас) в основном для установки различных драйверов.

Приход Windows 2000

Настоящий прорыв в области управления инсталляцией программ произошел с появлением Windows2000, которая принесла с собой очень много нового. Я не буду рассматривать все новшества, а упомяну только те, что касаются управления инсталляцией программ: это Windows File Protection и… Windows Installer. Эти технологии тесно связаны друг с другом. Первая позволяет решить извечную проблему Windows: так называемый DLL Hell. Вторая, которой собственно и посвящена эта статья, гораздо шире и сложнее. Рассмотрению вопроса, что же такое Windows Installer, для чего, где и как применяется, и будет посвящена оставшаяся часть статьи.

Windows Installer — новое слово в технологиях инсталляции

Глоссарий

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

Термин	Краткое описание
Внешний пользовательский интерфейс	Пользовательский интерфейс, не использующий встроенные возможности Windows Installer. Такой интерфейс использует, например, инсталлятор Microsoft Visual Studio .NET.
Встроенный пользовательский интерфейс	Пользовательский интерфейс, основанный на встроенных возможностях Windows Installer. Инсталляторы с таким интерфейсом работают в режиме Мастера, то есть инсталляция выполняется пошагово. Такой интерфейс используют, например, инсталляторы Microsoft Office 2000 и XP.
Патч (заплата)	Метод обновления файлов на уровне изменения байтов, а не замены файла целиком. Применяется при мелких обновлениях.
Инсталляционная база данных	Реляционная база данных, содержащая всю необходимую логику и данные для установки приложения
Инсталляция по требованию	Служба Installer, позволяющая устанавливать приложение или его опции только, когда их запрашивает пользователь или другое приложение
Код пакета	Глобально уникальный идентификатор (GUID) пакета (модуля инсталляции)
Компонент	Наименьшая часть инсталляции, обрабатываемая инсталлятором, а также часть функциональности приложения с точки зрения программиста
Обновление	Установка самой последней версии приложения
Операция	Инкапсуляция некоторой типичной функции, выполняемой во время инсталляции или обновления приложения.
Опция	Часть функциональности приложения, видимая со стороны пользователя
Оценка стоимости	Метод, используемый Windows Installer для оценки дискового пространства, необходимого приложению
Откат	Автоматическое восстановление оригинальной конфигурации компьютера при сбоях в установке
Пакет (модуль) инсталляции	Состоит из .msi-файла и внешних, связаных с ним файлов. Содержит всю логику, необходимую для установки и удаления приложения.
Подключаемый модуль	База данных, содержащая наборы компонентов. Позволяет создавать пакеты инсталляции из готовых наборов компонентов. Отдельно устанавливаться не может.
Пользовательская операция	Операция, определенная разработчиком пакета инсталляции.
Свойство	Глобальная переменная, используемая Windows Installer при инсталляции приложения
Стандартная операция	Встроенная в Windows Installer предопределенная операция, например, CreateShortcuts или InstallFiles.
Таблицы последовательности установки	Таблицы в инсталляционной базе данных, задающие правила установки
Трансформация	Шаблон изменений, используемый для добавления или замены элементов исходной базы данных. Применяется, например, для замены языка приложения.
Уровень базового пользовательского интерфейса	Уровень, при котором Windows Installer обеспечивает простой пользовательский интерфейс с немодальными диалогами. На этом уровне недоступно использование пользовательских диалогов.
Уровень инсталляции	Уровень, задаваемый для каждой инсталляции. Приложение устанавливается только если его уровень меньше или равен уровню инсталляции. Таким образом, можно управлять инсталляцией наборов приложений.
Уровень полного пользовательского интерфейса	Уровень, при котором можно задействовать все встроенные возможности пользовательского интерфейса Windows Installer
Уровень сокращенного пользовательского интерфейса	Уровень, при котором Windows Installer обеспечивает интерфейс с немодальными пользовательскими диалогами. Также могут использоваться встроенные модальные диалоги для сообщений об ошибках.
SQL (Structured Query Language)	Язык запросов, используемый для работы с реляционными базами данных. Windows Installer поддерживает ограниченное подмножество языка.

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

Что такое Windows Installer?

Windows Installer – это сервис установки и конфигурирования программных продуктов. Он поставляется как неотъемлемая часть операционных систем Windows 2000 и Windows Me, а также может устанавливаться в ОС Windows 95, Windows 98 и Windows NT 4.0 вместе с пакетами обновления этих операционных систем или в качестве отдельного дистрибутива.

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

Основная цель этой технологии: уменьшение так называемой совокупной стоимости владения (TCO – Total Cost of Ownership) для пользователей программных продуктов за счет эффективных средств развертывания и конфигурирования ПО. Надо отметить, что Windows Installer – это только часть (хотя и очень важная) усилий Microsoft по снижению стоимости развертывания, использования и сопровождения ПО для персональных компьютеров.

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

Выгода от использования Windows Installer для пользователей

Выгода от использования модулей инсталляции для Windows Installer заключается в том, что они облегчают процесс установки и обновления программных продуктов пользователям. Эти модули могут работать на любой 32-хбитной платформе Windows, начиная от Windows 95 и заканчивая Windows XP. Пользователи этих операционных систем получают много преимуществ от использования технологии Windows Installer, а именно:

• Более простая и быстрая установка программного обеспечения. Так как вся информация об установленном приложении содержится в одном месте, разработчик может предугадать ответы на многие вопросы пользователя, освобождая тем самым пользователя от принятия сложных решений во время установки или обновления программного продукта.
• Возможность установки по требованию. Информация о неустановленных компонентах приложения также хранится в одном месте. Значит, если вдруг пользователь захочет использовать компонент, который еще не установлен, ему не придется снова запускать весь инсталляционный пакет только для того, чтобы добавить еще одну возможность в программу. Когда пользователь решает использовать новый компонент, приложение просто проверяет инсталляционные данные и извлекает нужную информацию, позволяя добавлять нужную функциональность по требованию.
• Самовосстановление программ. Хранение инсталляционной информации в одном месте позволяет приложению самовосстанавливаться. Поэтому пользователи теряют меньше времени на удаление и переустановку приложений, а также избавляются от необходимости исправлять непонятные и трудно диагностируемые ошибки в конфигурации приложения. Неправильно работающее приложение может проверить инсталляционные данные, определить, какие файлы повреждены или отсутствуют, а затем восстановить их.
• Мощные возможности отката. Windows Installer позволяет отменять любые изменения в конфигурации как устанавливаемого продукта, так и операционной системы. Это делает установку программ, поддерживающих технологию Windows Installer, намного более безопасным и предсказуемым занятием, чем каких-либо других. Если при установке программы пользователь сталкивается с фатальной ошибкой, которая прерывает процесс инсталляции, у него остается возможность вернуться к предыдущему устойчивому состоянию. Причем это состояние будет в точности таким, каким было до попытки установки нового программного продукта. Такое поведение программ очень сильно отличается от того, к которому мы привыкли за много лет. Сбой или ошибки в программе инсталляции любого продукта (особенно заменяющего системные динамические библиотеки) могли нарушить работоспособность всей системы, причем это было справедливо не только для практически незащищенных операционных систем типа Windows 9x, но и для Windows NT. Я сам не раз сталкивался с подобными проблемами, особенно при отладке инсталлятора для довольно большого продукта, созданного с использованием пакета InstallShield Professional.

Выгода для пользователей Windows 2000 и более новых систем

Пользователи этих систем получают еще больше преимуществ, а именно:

• Публикация приложений
• Установка приложений на \»закрытых\» машинах

Публикация приложений

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

Администраторы систем Windows 2000 могут использовать эту возможность для добавления иконок приложений в меню Пуск сразу на многих машинах без установки программ до тех пор, пока они реально не понадобятся пользователю. Это позволяет системным администраторам поддерживать единую рабочую среду на множестве компьютеров под управлением Windows 2000, а пользователям иметь доступ ко всем приложениям, и в то же время не устанавливать ненужные на данный момент программы.

Установка приложений на \»закрытых\» машинах

Администраторы систем Windows 2000 могут разрешать пакетам инсталляции запускаться с привилегиями администратора на пользовательских машинах. Это позволяет устанавливать программное обеспечение на \»закрытых\» Windows 2000 компьютерах, то есть на таких компьютерах, где обычные пользователи не имеют привилегий делать то, что позволяется делать программе инсталляции.

Выгода от использования Windows Installer для разработчиков

То, что пользователям выгодно использовать данную технологию, сомнений не возникает. Но мы-то с вами не рядовые пользователи, мы – разработчики программного обеспечения (на мой взгляд, это должно звучать гордо). Что нам дает Windows Installer, кроме еще одной головной боли от необходимости изучать нечто новое? А вот что (и это немало):

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

Я думаю, тот, кто работал с InstallShield Professional (пакет для создания инсталляций, управляемых скриптом) и InstallShield Developer (пакет для создания инсталляций на основе Windows Installer),

Раньше InstallShield Developer назывался InstallShield for Windows Installer поймет, насколько более гибко последний позволяет управлять созданием разных инсталляций на основе единого набора данных.

ПРИМЕЧАНИЕ Раньше InstallShield Developer назывался InstallShield for Windows Installer Что касается первого утверждения, непонятного на первый взгляд, то в нем все просто. Посмотрите на следующий заголовок – он все объясняет. Инсталляция, управляемая данными Традиционно программы инсталляции используют для управления процессом установки программ скрипты. Каждая инсталляционная программа содержит скрипт, то есть набор инструкций по установке конкретного программного продукта. Эти жестко закодированные инструкции могут прекрасно работать для данной конкретной инсталляции, но они же могут вызывать проблемы в случаях переустановки или удаления продукта, а также установки новых версий. Более того, эти проблемы могут возникнуть при инсталляции других программ, о которых вы даже не подозревали, когда писали свой скрипт. К тому же, так как информация о приложениях не разделяется между скриптами, администраторам и пользователям трудно управлять инсталляцией приложений. Новая, управляемая данными технология Windows Installer позволяет решить многие проблемы инсталляторов, управляемых скриптами. В модели инсталляции, управляемой данными, создается набор инсталляционных таблиц, в которых каждый ресурс (файлы, ключи реестра и т.д.) явным образом привязан к компоненту или опции приложения, которые его используют. При создании этих таблиц разработчик больше думает о том, что он устанавливает, вместо того, чтобы думать о том, как это устанавливать. То есть разработчик фокусируется на объектах, которые нужно установить и на местоположении этих объектов на целевой машине, а Windows Installer обеспечивает всю остальную функциональность. Тем не менее, это не освобождает разработчика от необходимости думать о том, как же будет устанавливаться приложение. ПРИМЕЧАНИЕ Все вышесказанное взято из документации Microsoft. Многие разработчики (в том числе и я) не во всем согласны с этими утверждениями. Но нельзя отрицать и того, что технология Windows Installer все-таки здорово облегчает жизнь системным администраторам и разработчикам. Таким образом, мы плавно переходим от общих тем к более конкретным вопросам. В данной статье я ограничусь рассмотрением Пакета инсталляции. Остальные вопросы, а именно: интерфейс пользователя, последовательность выполнения инсталляции, свойства, стандартные и пользовательские операции, включаемые модули и многие другие, будут рассмотрены в следующих статьях. Структура пакета инсталляции Windows Installer Итак, что же представляет собой пакет инсталляции для 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; системные таблицы; таблицы поиска; таблицы информации о программе; таблицы процесса инсталляции; Базовые таблицы Эта группа состоит из таблиц, описывающих основные опции и компоненты приложения и пакета его инсталляции. Эта группа должна заполняться в первую очередь, так как от ее содержимого зависит организация всей остальной части базы данных. ПРИМЕЧАНИЕ На этой и на последующих диаграммах черный круг, соединенный с белым ромбом обозначает отношение один-ко-многим между первичным ключом в первой таблице и внешним ключом во второй. Таким образом, мы видим, что эта группа состоит из 11 связанных таблиц. Ниже приведены их краткие описания: Имя таблицы Краткое описание Feature Содержит список всех функций программного продукта Condition Содержит условия определяющие порядок установки каждой функции, описанной в таблице Feature 1 FeatureComponents Связывает функции с компонентами, иными словами – эта таблица определяет, какой функции принадлежит компонент 2 Component Содержит список всех компонентов приложения Directory Содержит список всех каталогов, необходимых для инсталляции PublishComponent Содержит список функций и компонентов, публикуемых для использования в других приложениях Assembly Задает установки для сборок .NET Framework CLR и Win32 AssemblyName Задает схему для именования сборок .NET Framework CLR и Win32 Complus Содержит информацию, необходимую для установки приложений COM+ IsolatedComponent Связывает компонент, заданный в столбце Component_Application (обычно .exe) с компонентом, заданным в столбце Component_Shared (обычно .dll) Upgrade Содержит информацию для значительных обновлений программного продукта 3 ПРИМЕЧАНИЕ Если в таблице Condition нет условия для функции из таблицы Feature – это значит, что функция будет установлена в любом случае. Один компонент может быть связан с несколькими функциями. В данном случае под термином значительное обновление понимается обновление, приводящее к изменению свойства ProductCode. Я не буду останавливаться на обновлениях, так как эта тема заслуживает отдельной статьи. Файловые таблицы Эта группа таблиц содержит информацию обо всех файлах, составляющих программный продукт. Большая часть этих файлов перечислена в таблице File. Таблица Directory не входит в эту группу, но, тем не менее, очень тесно связана с ней, так как отражает структуру каталогов приложения. При разработке инсталляционного пакета эта группа таблиц должна заполняться после того, как приложение разбито по функциям и компонентам и заполнена группа Базовых таблиц. ПРИМЕЧАНИЕ Такие пакеты как InstallShield Developer и Wise Installer позволяют не придерживаться такого жесткого порядка заполнения таблиц. Но рекомендуется все-таки тщательно продумать структуру пакета инсталляции перед тем, как начать заполнять базу данных. Эта группа состоит из 15 таблиц. Их краткое описание дано ниже. Имя таблицы Краткое описание File В этой таблице перечислены файлы, входящие в инсталляцию. Так как файлы привязаны к компонентам, их использующим, эта таблица связана с таблицей Component RemoveFile В этой таблице содержится список файлов, которые необходимо удалить при выполнении операции RemoveFiles Font Эта таблица содержит список файлов шрифтов, которые необходимо зарегистрировать в системе SelfReg Эта таблица содержит список саморегистрирующихся модулей (то есть библиотек динамической компоновки, экспортирующих функции DllRegisterServer и DllUnregisterServer). Installer не регистрирует EXE-файлы Media Эта таблица описывает набор дисков инсталляции BindImage Эта таблица содержит информацию о привязках исполняемых файлов или DLL 1 MoveFile Эта таблица содержит список файлов, которые нужно перенести или скопировать во время инсталляции из исходного каталога в заданный каталог DuplicateFile Эта таблица содержит список файлов, которые необходимо продублировать при инсталляции: либо в другой каталог с тем же именем, что и исходный файл, либо в тот же каталог, но с другим именем IniFile В этой таблице содержится информация для создания .ini-файлов, необходимых приложению. Эти файлы создаются, если содержащий их компонент выбран для инсталляции в локальном режиме или с источника инсталляции RemoveIniFile Эта таблица содержит информацию, которую необходимо удалить из .ini-файлов при инсталляции приложения Environment Эта таблица используется для задания переменных окружения 2 Icon Эта таблица хранит файлы иконок. Каждая иконка этой таблицы во время инсталляции копируется в отдельный файл на диске 3 FileSFPCatalog Эта таблица используется системой Windows File Protection в ОС Windows Me SFPCatalog Эта таблица также используется системой Windows File Protection в ОС Windows Me MsiFileHash Эта таблица хранит 128-разрядное хэш-значение для исходных файлов в пакете инсталляции 4 ПРИМЕЧАНИЕ Для получения более подробной информации о привязках смотрите описание функции Windows API BindImageEx В операционных системах Windows95/98 в этой таблице также хранится список изменений в файле autoexec.bat Таблица Icon используется при публикации программных продуктов Таблица MsiFileHash может использоваться только для файлов, не содержащих информации о версиях. Windows Installer может использовать информацию из этой таблицы, чтобы не выполнять лишнее копирование файлов, уже содержащихся на пользовательском компьютере и совпадающих с файлами из пакета инсталляции. Таблицы записей в реестре Windows Эта группа содержит таблицы, описывающие различные виды информации в реестре Windows. Внимательный читатель, конечно же, заметил, что на рисунке присутствуют таблицы из других групп, такие, как Component, Feature и File. Эти таблицы включены сюда для того, чтобы более ясно показать логику работы этой группы. Кроме того, здесь присутствуют таблицы, уже упоминавшиеся в других группах, но здесь играющие немного другую роль (это таблицы SelfReg и Environment). Таким образом, эта группа включает 11 таблиц, краткое описание которых дано ниже: Имя таблицы Краткое описание Extension Эта таблица содержит список расширений файлов, используемых устанавливаемой программой, вместе с привязанными к этим расширениям функциями и компонентами Verb Эта таблица связывает информацию о командах, связанных с расширениями файлов из предыдущей таблицы. Наличие этих таблиц в связке с таблицей Feature позволяет реализовать возможность публикации приложения TypeLib Эта таблица содержит записи, необходимые для регистрации библиотек типов 1 MIME Эта таблица связывает типы MIME c CLSID или расширением файла. Это позволяет связать таблицы MIME и Feature, и обеспечить еще один путь для публикации приложения SelfReg Смотрите описание в группе Файловые операции 2 Class Эта таблица содержит информацию, необходимую для работы COM-серверов ProgId Эта таблица содержит информацию о ProgID для COM-серверов AppId Эта таблица используется для конфигурирования DCOM-серверов Environment Смотрите описание в группе Файловые таблицы 3 Registry Эта таблица содержит всю прочую информацию, не вошедшую в другие таблицы. Это может быть пользовательская информация, данные, установки по умолчанию и т.д. RemoveRegistry Эта таблица содержит информацию о записях в реестре, которые нужно удалить при инсталляции приложения ПРИМЕЧАНИЕ При публикации приложения никаких записей о библиотеках типов не делается. Запись производится только в момент установки компонента, связанного с библиотекой. Использование саморегистрации в Windows Installer НЕ РЕКОМЕНДУЕТСЯ и включено только для обеспечения обратной совместимости с предыдущими технологиями установки программ. Вместо этого рекомендуется заполнить соответствующие таблицы нужной информацией, аналогичной той, что прописывает нужный модуль при вызове его функции DllRegisterServer. Эта таблица включена в данную группу, так как в операционных системах Windows NT / 2000 / XP данные из нее пишутся в реестр. СОВЕТ При заполнении этой группы нужно попытаться сделать таблицу Registry как можно компактней, поместив как можно больше информации в другие, более специфичные таблицы. Это делается, потому что Installer не может выделить различные типы реестровых записей в таблице Registry и, следовательно, не может использовать внутреннюю логику для задействования всех своих возможностей, например – публикации или установки по требованию. Кроме того, такой способ организации данных поможет уменьшить риск записи лишней информации о COM-серверах. Системные таблицы Эта группа содержит информацию о структуре инсталляционной базы данных. Запросы к таблицам этой группы позволяют получить разнообразную информацию о пакете инсталляции любого приложения. Диаграмму этой группы приводить смысла нет. Некоторые таблицы этой группы – статические, они создаются при компиляции пакета инсталляции и не связаны с другими таблицами. Другая же часть вообще не хранится в базе данных, а создается только на время выполнения SQL-запросов. Итак, эта группа состоит из 5 таблиц, краткое описание которых дано ниже: Имя таблицы Краткое описание _Tables Хранит имена всех таблиц инсталляционной базы данных, включая созданные автором пакета для личных целей (например, для использования в своих операциях). Эта таблица доступна только на чтение _Columns Хранит информацию обо всех столбцах в таблицах инсталляционной базы данных. Но временные столбцы в этой таблице не хранятся. Как и предыдущая таблица, доступна только на чтение _Streams Содержит потоки данных OLE. Эта таблица временная и создается только при выполнении определенных SQL-запросов, например, при выполнении функции MsiRecordReadStream _Storages Содержит хранилища данных OLE. Эта таблица также временная и создается только при выполнении определенных SQL-запросов, например, при выполнении функции MsiRecordSetStream _Validation Эта таблица содержит информацию о столбцах в таблицах базы данных, включая их имена и диапазоны допустимых значений, а также другую важную для базы данных информацию. Используется только при проверке целостности базы данных Таблицы поиска Таблицы поиска используются для поиска файлов и приложений на компьютере пользователя. Чтобы найти файл, нужно сначала задать сигнатуру файла, а затем произвести поиск. Таблицы этой группы можно использовать для поиска в реестре, в данных конфигурации инсталлятора, по дереву каталогов или в .ini-файлах. При этом ищется файл или каталог с заданной уникальной сигнатурой. Затем, если файл найден, его сигнатура проверяется по таблице Signature, чтобы убедиться, что данный файл действительно тот, который нужен, а не просто еще один файл с таким же именем. Если запись в таблице поиска не связана с таблицей Signature, значит, запись ссылается на каталог, а не на файл. Компонент, которому принадлежит нужный файл, определяется через связь между таблицами File и Component. Installer определяет подчиненность файла через таблицу компонентов, потому что каждый файл связан с одним компонентом. Местоположение компонента определяется по внешнему ключу в таблице Component, указывающему на таблицу Directory. Нужные приложения ищутся аналогично: при этом находятся определенные файлы, из которых состоит приложение. Installer также предоставляет две таблицы, позволяющие искать предыдущие версии приложений: AppSearch и CCPSearch. Группа таблиц поиска состоит из 7 таблиц, описание которых дано ниже: Имя таблицы Краткое описание Signature Содержит информацию, уникальным образом описывающую некоторый файл 1 RegLocator Эта таблица содержит информацию, необходимую для поиска файлов или каталогов по записям в реестре IniLocator Эта таблица используется для поиска .ini-файлов. Эти файлы должны быть расположены в корневом каталоге Windows CompLocator Эта таблица используется для поиска файлов или каталогов с использованием конфигурационных данных Windows Installer DrLocator Эта таблица используется для поиска по дереву каталогов AppSearch Эта таблица содержит список свойств, которые должны быть установлены, если нужный файл или каталог с заданной сигнатурой найден CCPSearch Эта таблица содержит список сигнатур файлов, из которых хотя бы один должен быть установлен на пользовательском компьютере. Таблица используется при обновлении программ ПРИМЕЧАНИЕ Формально по документации Microsoft таблица Signature не относится к группе таблиц поиска. Но так как она нигде, кроме поиска, не используется, я позволил себе внести ее в эту группу. Таблицы информации о программе Таблицы этой группы содержат важную информацию о пакете инсталляции, используемую на протяжении всего процесса инсталляции. Состоит эта группа из пяти таблиц: Имя таблицы Краткое описание Property В этой таблице хранятся все свойства 1 пакета инсталляции Binary В этой таблице хранятся двоичные данные для иконок, растров и т.п. Также здесь хранятся данные для пользовательских операций Error Эта таблица используется для поиска шаблонов форматирования при обработке ошибок. Installer имеет свой собственный механизм обработки ошибок Shortcut Здесь хранится вся информация, необходимая для создания файловых ярлыков ReserveCost Эта таблица содержит информацию о необходимом дисковом пространстве для каждого компонента приложения ПРИМЕЧАНИЕ Свойство – это глобальная переменная, которая используется Microsoft Windows Installer во время инсталляции. Таблицы процесса инсталляции Таблицы этой группы управляют выполнением стандартных и пользовательских операций. ПРИМЕЧАНИЕ Тема операций в Windows Installer обширна и ей будет посвящена одна из следующих статей. Некоторые из таблиц этой группы управляют последовательностью выполнения операций на самом высоком уровне. Каждая из следующих таблиц управляет своей частью процесса. Имя таблицы Краткое описание InstallUISequnce Эта таблица содержит операции, выполняемые при активизации высокоуровневой операции INSTALL и уровне пользовательского интерфейса – полный или сокращенный. Installer пропускает операции из этой таблицы, если уровень пользовательского интерфейса установлен в базовый или отключен 1 InstallExecuteSequence Эта таблица содержит операции, выполняемые при активизации высокоуровневой операции INSTALL 1, 2 AdminUISequence Эта таблица содержит операции, выполняемые при активизации высокоуровневой операции ADMIN и уровне пользовательского интерфейса – полный или сокращенный. Installer пропускает операции из этой таблицы, если уровень пользовательского интерфейса установлен в базовый или отключен 3 AdminExecuteSequence Эта таблица содержит операции, выполняемые при активизации высокоуровневой операции ADMIN 2, 3 AdvtUISequence Installer не использует эту таблицу. Она должна быть удалена из базы данных или быть пустой AdvtExecuteSequence Эта таблица содержит операции, выполняемые при активизации высокоуровневой операции ADVERTISE 4 ПРИМЕЧАНИЕ Все операции в последовательности инсталляции, вплоть до InstallValidate и диалогов выхода, помещаются в таблицу InstallUISequence. Все операции от InstallValidate и до конца инсталляции – в таблицу InstallExecuteSequence. Так как последняя таблица может использоваться независимо от первой (например, если пользовательский интерфейс отключен), она включает все операции инициализации, такие как LaunchConditions, CostInitialize, CostFinalize и ExecuteAction. Все пользовательские операции, выполняемые в этой последовательности, при необходимости использования пользовательского интерфейса должны пользоваться функцией API MsiProcessMessage, вместо диалогов из таблицы Dialog. Все операции в последовательности инсталляции, вплоть до InstallValidate и диалогов выхода, помещаются в таблицу AdminUISequence. Все операции от InstallValidate и до конца инсталляции – в таблицу AdminExecuteSequence. Так как последняя таблица может использоваться независимо от первой (например, если пользовательский интерфейс отключен), она включает все операции инициализации, такие как LaunchConditions, CostInitialize, CostFinalize и ExecuteAction. Таблица AdvtExecuteSequence может содержать только ограниченный набор стандартных операций. Пользовательские операции не должны содержаться в этой таблице. К другой группе относятся таблицы, позволяющие расширять функциональность пакета инсталляции. Достаточно часто, особенно при установке сложных программных продуктов, встроенной функциональности Windows Installer, основанной на стандартных операциях, не хватает. Здесь и приходит на помощь таблица Custom Action, позволяющая создавать и хранить в инсталляционной базе данных информацию для выполнения пользовательских операций. Эта таблица позволяет легко и просто интегрировать пользовательский код и данные в процесс инсталляции приложения. Исполняемый код может браться прямо из базы данных, только что установленного файла или из уже существующего на компьютере исполняемого файла. Следующая группа таблиц расширяет возможности инсталлятора по манипулированию файлами и каталогами в процессе инсталляции. Имя таблицы Краткое описание RemoveFile Эта таблица содержит список файлов, которые необходимо удалить при инсталляции RemoveIniFile Эта таблица содержит информацию, которую нужно удалить из .ini-файлов при инсталляции приложения RemoveRegistry Эта таблица содержит информацию, которую нужно удалить из реестра при инсталляции связанного с ней компонента CreateFolder Содержит список каталогов, которые необходимо создать при инсталляции приложения 1 MoveFile Эта таблица содержит список файлов, которые нужно перенести или скопировать во время инсталляции из исходного каталога в заданный каталог ПРИМЕЧАНИЕ Хотя Installer и создает при инсталляции каталоги по мере необходимости, они удаляются, если не содержат файлов. Каталоги, перечисленные в таблице CreateFolder, не удаляются до тех пор, пока не будет удален связанный с ними компонент. И, наконец, последняя в списке, но далеко не последняя по значимости таблица, управляющая выполнением инсталляции: LaunchCondition. Эта таблица содержит список условий, при выполнении которых может начаться процесс инсталляции. Следует заметить, что эта таблица управляет процессом в целом и для успешного запуска процесса инсталляции необходимо выполнение ВСЕХ содержащихся в ней условий. Последнее слово о таблицах Список таблиц, используемых Windows Installer, весьма велик. И вполне естественно, что в рамках статьи невозможно рассмотреть все из них. Многие из таблиц, не упоминавшихся здесь, будут рассмотрены в следующих статьях, при рассмотрении более узких тем. Windows Installer API Таблицы – это конечно, хорошо. Но как добраться до содержимого этих таблиц? И как изменять эти таблицы? То есть, говоря иными словами, как можно работать с базой данных инсталляционного пакета? Для этого существует Windows Installer API. Этот API весьма обширен и включает в себя несколько десятков функций, различных констант и агрегатных типов данных. Все функции Windows Installer API поддерживают как ANSI, так и Unicode. Это позволяет использовать их как в операционных системах на основе Windows NT, для которых кодировка Unicode является родной, так и в системах Windows 9x, ограниченно поддерживающих Unicode. Все функции Windows Installer API легко найти по префиксу – Msi. Функции API можно условно разделить на две большие группы: Функции общего назначения. Функции доступа к инсталляционной базе данных. Функции общего назначения Эта большая группа функций делится на следующие группы: Функции пользовательского интерфейса и журналирования. Функции управления дескрипторами. Функции конфигурирования и инсталляции. Компоненто-ориентированные функции. Функции приложения. Функции статуса системы. Функции запросов. Функции исправлений. Функции доступа к инсталляционной базе данных Функции доступа к базе данных используются в пользовательских операциях, выполняемых во время инсталляции программ, и в инструментальных утилитах (например, в тех же ORCA и MsiSpy из Platform SDK). Некоторые из этих функций используют подмножество языка SQL для запросов к базе данных. Функции доступа к базе данных можно разделить на следующие группы: Общие функции – эта группа функций используется для открытия, закрытия базы данных, работы с представлениями базы данных. Функции управления – эта группа используется в основном для работы с трансформациями, а также для объединения баз данных, и их импорта/экспорта в текстовые файлы. Функции обработки записей – это различные функции для манипулирования записями базы данных. С помощью этих функций можно извлекать данные из базы и помещать их туда. В Windows Installer поддерживаются следующие типы записей: String – строка, заканчивающаяся нулем, Integer – 32-битное целое число и Stream – поток байтов произвольной длины. Функции для работы c суммарной информацией – эта группа функций позволяет извлекать из базы и записывать в базу свойства суммарной информации. Функции доступа к состоянию инсталлятора – эти функции позволяют получать и задавать различные свойства инсталлятора. Функции выполнения операций – эта группа функций используется для выполнения пользовательских и стандартных операций, вычисления условий и обработки сообщений. Функции поиска — эти функции позволяют получать и записывать информацию в таблице Directory. Функции выбора – эта группа функций используется для работы с функциями приложения и компонентами.Также в нее входят функции для установки уровня инсталляции и оценки места на диске, необходимого как для установки отдельных компонентов приложения, так и для всего продукта в целом Функции пользовательского интерфейса – эти функции используются в инструментальных средствах для предварительного просмотра диалоговых окон и различных Заключение На этом я хочу закончить первую часть цикла. Надеюсь, что вы получили достаточно ясное общее представление о технологии Windows Installer и преимуществах ее применения для инсталляции программных продуктов. В следующей статье я хочу рассказать о том, как же собственно выполняется инсталляция приложений, какие процессы при этом происходят, и какие данные из вышерассмотренных таблиц используются. Читайте также:  Windows calendar app android Оцените статью Вам также может понравиться Windows или Linux: Что лучше выбрать? Есть много причин выбирать между Windows и Linux, но Файл владелец изменить linux Команда Chown в Linux Chown Command in Linux (File Установка шлюза по умолчанию linux Настройка сети вручную Содержание Краткое описание Чем разбить диск для linux ИТ База знаний Курс по Asterisk Полезно — Узнать IP — Правообладателям Политика конфиденциальности Контакты