Администраторы систем 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 и некоторые другие, не столь широко известные пакеты. Кстати, многие пакеты создания инсталляторов включают в базу данных свои дополнительные таблицы, например, в пакетах, созданных с помощью
