Технология унифицированной установки Windows-приложений до сих пор не получила всеобщего признания
Во время работы Windows Installer выполняет преобразование данных, хранящихся в файле MSI в сценарии установки и удаления программы

Нет кошмару DLL! Этот лозунг был провозглашен корпорацией Microsoft около четырех лет назад, когда одновременно с Windows 2000 была представлена технология Windows Installer. Теперь она доступна не только пользователям Windows 2000, Windows XP и Windows Server 2003, но также и тем, кто работает с более ранними версиями Windows (последним требуется установить соответствующие пакеты Service Packs). Технология Windows Installer была преподнесена корпорацией как долгожданное средство столь необходимой унификации процесса установки Windows-приложений.

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

К чему это в итоге приводило? Классической проблемой была следующая: некоторое приложение, установившее динамическую библиотеку в системный каталог Windows, через какое-то время перестает работать. Причина: появление еще одного приложения, с успехом заменяющего старую библиотеку в процессе своей установки более новой (и не всегда совместимой с прежней) версией. Программы деинсталляции в то время удаляли DLL и изменяли ключи реестра тоже без оглядки на их использование другим ПО.

Как это работает

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

Для работы со службой Windows Installer разработчикам необходимо было заменить традиционные скрипты установки приложений на пакетные файлы Windows Installer (имеющие расширение MSI). И поскольку при этом отслеживаются только установки, выполненные по правилам Windows Installer и с использованием файлов MSI, по-настоящему ощутить положительный эффект от применения этой технологии можно только в том случае, когда все приложения, устанавливаемые на компьютер под управлением ОС Windows, поддерживают Windows Installer.

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

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

Служба Windows Installer отслеживает все изменения, вносимые в систему в процессе установки компонентов. Если один и тот же компонент используется несколькими приложениями, это отражается в соответствующем счетчике. Кроме того, каждому компоненту назначается уникальный глобальный идентификатор (GUID), а также собственный ключ реестра KeyPath. Отслеживая ссылки на компоненты, а не на отдельные ресурсы, Windows Installer может контролировать все совместно используемые ресурсы, а не только файлы. Библиотеки DLL и другие ресурсы удаляются только при удалении последнего компонента, их использующего.

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

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

Объединенные в группы средства поддержки различного рода функциональности в свою очередь могут совместно с другими группами (и другими приложениями) использовать те или иные компоненты. Их можно устанавливать как запускаемые с компакт-диска, локального или сетевого жесткого диска. Возможен и вариант установки тех или иных функций как «заявленных». Иными словами — в меню приложения такая функция будет присутствовать, но реальную ее установку пользователь инициирует только после того, как в первый раз к ней обратится. И все это разнообразие инсталляционных возможностей включается в единственный для конкретного приложения MSI-файл.

Плюс API

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

Системные администраторы могут адаптировать файлы MSI под свои нужды, создавая сопутствующие файлы преобразования (MST). Суть такой адаптации заключается в автоматизированной подстановке и передаче службе Windows Installer ответов пользователя на запросы, которые инициируются при обработке MSI-файла. Например, таким образом могут задаваться параметры установки приложения или каталоги для установки файлов, удаляться ненужные компоненты и функциональные части.

Однако разработчики ПО по-прежнему не торопятся переходить на использование формата MSI. Как уже говорилось выше, прошло около четырех лет после выпуска дебютного варианта Windows Installer, а во многих приложениях все также используются другие средства установки.

Windows Installer в действии

Рассмотрим принцип построения MSI-файла на примере Microsoft Office. Пакетный файл Windows Installer для этого продукта содержит сведения обо всех программах (представленных как функциональные группы), входящих в его состав, а также всех функциях, которые могут быть предоставлены пользователю. Каждая функция ассоциируется со своими компонентами, а те в свою очередь связаны с ресурсами (файлами, ключами системного реестра и др.). При этом ресурсы объединяются в группы и в таком виде устанавливаются на компьютер. Тем самым обеспечивается возможность установки и удаления различных компонентов, не затрагивая при этом ресурсы

Источник: Microsoft