Создание лучшей инсталляции

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

 This article is also available in English 

Выбирайте правильные библиотеки DLL

Причина номер один, почему люди не доверяют инсталляциям, потому что они ожидают, что инсталляция заменит системную библиотеку и сломает другие приложения. Эта ситуация обычно называется
“DLL Hell”. Мы будем говорить о системе защиты файлов Windows (Windows File Protection) позднее, но хорошие новости - это уже то, что Microsoft упаковывает распространяемые библиотеки в инсталляции, таким образом, относительно редко может потребоваться отбирать и выбирать отдельные библиотеки для распространения. Некоторые из стандартных пакетов перечислены в Таблице 1. Когда Вы запускаете такие пакеты инсталляции, они инсталлируют подходящие библиотеки, поддерживаемые приложением. Если Вы зададите поиск на WEB сайте Microsoft по именам этих пакетов, Вы найдете подробную информацию, какие библиотеки они инсталлируют. Файл Redist.txt в Наборе инструментов разработчика программ для Платформы (Platform SDK) также содержит список пакетов, которые должны быть использованы для инсталляции поддержки таких функций, как Стандартные Элементы управления и Категории Компонент. С другой стороны, файл Redist.txt распространяемый с Visual Studio 6.0 может доставить Вам много хлопот, если Вы не будете осторожны. К примеру, его список содержит RPCRT4.DLL, декларируемую как "Стандартный Распространяемый код", и когда Вы запускаете предпочитаемый Вами анализатор зависимостей, он сообщает Вам, что RPCRT4.DLL является зависимой, и Вы можете начать думать о том, что Вам нужно установить эту библиотеку на все Ваши клиентские системы. Однако эта библиотека является стандартной частью операционной системы с самого момента появления Windows 9x, и ее инсталляция на клиентской системе, вероятно, ее сломает. Мои подозрения заключаются в том, что дата создания этого списка распространяемых файлов совпадает с датой выпуска Windows 95, и не содержит функциональность, добавленную позднее (такую как COM). В этой связи, если Ваше приложение запускается под управлением самых ранних версий Windows 95, DCOM95.EXE является пакетом, который устанавливает RPCRT4.DLL и другие библиотеки COM.
Вы также должны быть осторожны с библиотеками, поддерживающими код, написанный с использованием Visual C++ ATL. Библиотека ATL.DLL может быть версий ANSI для Windows 9x и Unicode для Windows NT, обе с одинаковым названием. Новейшие операционные системы Windows оснащены системой защиты файлов Windows. Она разработана, чтобы не допустить инсталляционным программам заменить приблизительно 2700 (в Windows 2000) критически важных системных библиотек DLL, элементов визуального управления OCX и драйверов, которые обеспечивают безотказное состояние системы.
Время от времени людьми предпринимаются попытки обойти эту защиту, типично это, потому что их приложения не работают с версиями, на сохранении которых в системе настаивает Windows. Если они смогут получить "правильную" версию в системе, их приложение будет работать. Суровая действительность заключается в том, что приложение окажется сломанным, если оно не сможет работать с системными библиотеками в системе с защитой файлов Windows.
Вы можете получить список защищенных файлов, откомпилировав и запустив программу, приведенную в Примере №1. Вам потребуется установить ссылку на SFC.LIB в установках Вашего проекта. Я мог также упоминать о том, что компания Microsoft реализовала схему, названную "бок-о-бок" для компонент, предназначенную сократить конфликты, происходящие, когда многие приложения используют одни и те же библиотеки. Также, помните, что распространяемые файлы сильно отличаются от приложений .Net. Мы будем обсуждать это позднее.

Своевременно обновляйте распространяемые файлы
новыми версиями

Итак, приложение один раз должным образом установлено и корректно работает, но это только начало. Microsoft будет отправлять Сервисные обновления
(Service pack) для операционной системы и поддерживать новые распространяемые файлы из сервисных обновлений для Visual Studio. Новые версии компонент MDAC, Internet Explorer, SQL Server и других продуктов, будут установлены в системе клиента и обновят библиотеки. Даже хотя у вас нет необходимости в установке каких-нибудь новых дистрибутивов для вашего приложения, вам все же нужно протестировать, что ваше приложение все еще будет работать с ними. Вы не сможете удержать другие продукты и другие инсталляции помещать новые версии программ Microsoft в систему, так обеспечьте, чтобы ваше приложение с ними работало.

Персональные установки

Одна из других причин, почему люди обеспокоены вопросом инсталляции, это то, что инсталлятор может изменить ваши персональные установки, даже не спросив вашего разрешения. Инсталляции не должны изменять установки активного рабочего стола (Active Desktop), рисунок рабочего стола (wallpaper), экранные заставки и т.д. Эти установки принадлежат вашему пользователю, не вам, и если вам действительно необходимо изменить их (а я сомневаюсь в том, что это действительно необходимо), всегда запрашивайте разрешение. Аналогичная ситуация может произойти с приложением, которая управляет расширениями файлов. Например, возможно вы наблюдали, что приложения, управляющие файлами HTML и различными файлами мультимедиа предполагают, что просто так как вы устанавливаете программу, вы захотите сделать ее управляющей всеми этими расширениями файлов по умолчанию. Если программа инсталляции получила информацию о том, что в системе уже есть программы, управляющие конкретными расширениями файлов, хорошая идея в том, чтобы дать знать клиенту о том, что ваше приложение становится управляющей для этих файлов по умолчанию, и дать им возможность изменить это.

Не настаивайте на конкретной установке инсталляции

Представим, что Боб и Алиса разработчики прикладных программ. Одним утром, Алиса подошла к Бобу и сказала: "Послушай, Боб, моя программа требует Сервисное обновление 1 для Windows, но твоя программа всегда запускается перед моей, поэтому я хочу, чтобы ты протестировал ее с Сервисным обновлением, а не я". Боб захочет показать Алисе, что этот вопрос находится в ее компетенции, а не его. Однако вы часто сталкиваетесь с аналогичной ситуацией, когда первая программа является программой инсталляции. Но является ли хорошей идеей для программы инсталляции осуществлять проверки такого сорта? Сервисное обновление в дальнейшем может быть удалено, таким образом однократная проверка во время инсталляции программы кажется бессмысленной. Вы также обнаружите часто встречающиеся советы, что Сервисные обновления должны быть применены повторно после каждой инсталляции. Как и всегда есть люди, не доверяющие инсталляциям, и они будут устанавливать Сервисные обновления после инсталляции в любом случае, верят ли они, что система защиты файлов Windows сохранит эти файлы, или нет. Эти пользователи просто обеспокоены, что инсталляция заставит их в действительности устанавливать Сервисное обновление дважды. Здесь напрашивается вопрос: как поведет себя приложение в случае, если Сервисное обновление будет удалено. Это никак не связано со сбоями в приложении, потому что пользователь должен удалить Сервисное обновление, таким образом, правильный ответ здесь заключается в том, что приложения должны проверять свои требования к системе, и выводить понятные для пользователя сообщения каждый раз, если они не соблюдены.
Хотя в этом примере упоминаются Сервисные обновления, это верно и для похожих ситуаций, например для такой, как требование к версии Internet Explorer.
Существует много и других подобных случаев, которые обычно нацелены на то, чтобы помочь пользователю, но приводят к непредвиденным последствиям.
Вы можете увидеть ситуацию, когда инсталляция будет прервана в случае, если она не может получить ответ от другого компьютера на запрос утилиты ping, или не установлена часть аппаратного обеспечения. Все эти случаи представляют собой вариации одного вопроса: инсталляция выполняет проверки, направленные на защиту приложения, когда оно запустится. Подумайте об этих ситуациях, и выполняйте проверки везде, где это возможно, для того, чтобы сделать процесс инсталляции простым, надежным и подходящим для выполнения везде, где это удобно заказчику.

Инсталляция других программ установки

Обычным не является обнаружить инсталляции, которые также устанавливают другие приложения или обеспечивающие их работу программы, выпуск для этой цели отдельной программы инсталляции. Могут быть ситуации, когда такие действия не считаются правильными, однако в большинстве случаев это может помочь Вашим клиентам. Например, иногда вы обнаруживаете, что вам нужно установить новую версию Компонент доступа к данным Microsoft (MDAC), или предоставить поддержку для Консоли управления Microsoft (MMC), установив самораспаковывающуюся программу immc.exe. Если вы запустите их в пакетном режиме, то вы можете обнаружить, что он требуют версию Internet Explorer, которая не установлена в системе у клиента, таким образом, их инсталляция не выполнится. В других случаях, они могут требовать перезагрузки, так ваша программа инсталляции встретится с перезагрузкой, которую она не ожидала. В дополнение, представим, что ваше приложение должно устанавливаться в других странах. Вы должны не устанавливать Компоненты доступа к данным Microsoft (MDAC) английской локализации в операционной системе с другой локализацией. Во многих случаях, включая Консоль управления Microsoft (MMC), где присутствуют локализуемые версии используемого совместно программного обеспечения (другой пример - это Adobe Acrobat Reader) и вы не должны устанавливать английскую версию. Как и во врачебной клятве Гиппократа, первое правило инсталляции - это "Не нанеси вреда", так и в случае, если вы сомневаетесь, не устанавливайте это. Что лучше для клиента? Что ваше приложение не будет работать, или то, что вы установите неправильные версии файлы, и все приложения на компьютере клиента перестанут работать правильно? Помните, клиент всегда может быть снабжен инструкциями по загрузке для получения версий подходящей локализации.

Конфигурация и получение данных

Иногда инсталляция обращается за данными, или устанавливает некоторые параметры конфигурации во время установки. Многие пользователи находят это устрашающим. Это не выглядит очевидным, даже если им дать возможность просмотреть все еще раз в случае, если пользователи допустили ошибку и хотят ее исправить. С точки зрения пользователя, если инсталляция запрашивает у вас ввести имя пользователя или IP адрес, возможно, вы захотите знать, что произойдет, если срок действия имени пользователя закончится, и вы захотите изменить его, или потребуется изменить IP адрес. Помните, что это может быть первым случаем, когда клиент столкнулся с вашим приложением, и у него может не быть понятия о том, как он будет менять эти вещи в дальнейшем. Лучший ответ на эти предложения - это выполнять этап конфигурации в приложении, а не в инсталляции. Приложение должно содержать утилиту конфигурации, которая может быть использована, чтобы изменить настройки конфигурации в любой момент, если клиент захочет изменить их, а не только во время инсталляции. В большинстве случаев, вы можете установить такой порядок запуска приложения, что утилита конфигурации будет первой, что запустит пользователь. Существует и другая причина, по которой не стоит предлагать диалоги специальной конфигурации во время установки - инсталляция может обладать параметрами командной строки, отключающими интерфейс пользователя при установке. В этом случае, ваш клиент может захотеть сделать инсталляцию незаметной для пользователя или автоматизировать ее, потому что приложение должно быть развернуто на большом количестве систем, и диалоги конфигурации во время установки проигрывают требованиям клиента. В этом случае, ваш клиент может хотеть отключить пользовательский диалог или автоматизировать процесс инсталляции, потому что она должна быть развернута на большом количестве систем, и диалог конфигурации во время установки проигрывают перед желанием пользователя. В другой ситуации, вы можете обнаружить, что ваше приложение может быть доставлено предварительно установленным в системе, и клиенты даже не увидят процесса инсталляции, они просто запустят его прямо из меню Пуск, и будут использовать, - и у них никогда не будет возможности настраивать конфигурацию во время установки. Пока многие системы все еще требуют отдельного процесса установки, возможно также, что они могут быть доставлены клиенту сразу полностью установленными и готовыми к использованию, и ваше приложение может быть установлено клиентом на одних системах, но не установлено на других, это зависит от того, как решит группа маркетинга. Windows CE, серверные приложения, системы PDA и встроенная XP - это как раз те случаи, когда пользователь никогда не увидит процесса инсталляции. Иногда во время установки ожидается, что будет выполнен поразительно большой объем работ. Для примера, от инсталляции может потребоваться создать базу данных.

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

Лицензионные соглашения и файлы кратких инструкций (readme)

В отдельных случаях, Лицензионное Соглашение представляет собой определенный способ получения данных, потому что пользователь должен принять его перед тем, как продолжить инсталляцию. Это содержит те же потенциальные предложения, которые мы обсуждали ранее, о конфигурации и пользовательских диалогах во время инсталляции, так что подумайте о представлении Лицензионного Соглашения вне процесса инсталляции. Возможно, вы осведомлены, например, что последние версии Adobe Acrobat Reader более не показывают соглашение во время установки - оно выводится теперь, когда вы просматриваете первый документ Acrobat PDF. Инсталляции часто дают возможность вывести на печать файлы Readme, которые содержат самую последнюю и важную информацию, но у неопытного пользователя не возникнет идеи о том, где можно будет найти эту информацию в дальнейшем. Для инсталляторов, распространяемых на компакт-дисках, самое полезное место для расположения информации такого рода - это часть программы автоматического запуска (Autorun), которая запускается немедленно, сразу после того, как пользователь вставит компакт-диск. В качестве альтернативы, для по-настоящему последней и важной информаций может потребоваться размещение на WEB-сайте, таким образом, вы можете установить ссылку (url) на ваш сайт поддержки. Опять, помните, что может наступить день, когда ваше приложение будет доставлено предварительно установленным в систему, поэтому лицензионное соглашение или краткая инструкция (файл Readme), которые будут показаны во время установки, ничем не смогут помочь.

Не экономьте на разработке приложения

Для приложения не является обыкновенным, если оно разработано таким образом, что не начнет работать корректно, пока инсталляция не внесет изменения определенным способом. Например, программа установки может запросить конкретный набор записей реестра для каждого пользователя системы. Гораздо более сложной задачей является выполнение этого во время инсталляции. В результате программа будет пытаться найти записи реестра в ветке HKEY_CURRENT_USER, всегда, когда бы пользователь ни вошел в систему. Также это потенциально недоработанная конструкция, которая не принимает во внимание новых пользователей, которые могут войти в эту систему впервые, и для которых таким образом нет записей в HKEY_CURRENT_USER. Правильный подход к разработке приложения в этом случае - установить первоначальный набор записей реестра по умолчанию в ветке HKEY_LOCAL_MACHINE. Затем, когда приложение запустится впервые для конкретного пользователя, этот набор может быть использован для заполнения записей в HKEY_CURRENT_USER, и отсюда в дальнейшем формировать каждому отдельному пользователю для сохранения в HKEY_CURRENT_USER. Давайте теперь рассмотрим случай, затрагивающий управление программой. Разработчика инсталляции попросили установить ярлык программы в группу программ автоматического запуска (Startup program group). Это решение работает хорошо, за исключением того, что на самом деле оно не является тем, что требовалось. Группа программ автоматического запуска запускается только тогда, когда пользователь входит в систему, но в настоящем требуется запустить программу тогда, когда запускается система. Другая альтернатива - это разместить записи в реестре Windows NT в ключе HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Однако так программа тоже запустится, когда пользователь войдет в систему, и не запустится при перезагрузке системы. Возможен и другой интересный трюк - программа, не имеющая интерфейса пользователя и запускающаяся постоянно, так что когда придет время установить новую версию в системе Windows NT, инсталляция потребует перезагрузку системы, потому что исполняемые файлы использовались во время установки. Точку в этой истории можно поставить на том, что эти предложения инсталляции должны быть учтены во время разработки приложения. В этом конкретном случае, это может быть разновидность приложения, которая может быть реализована как служба Windows NT, потому что она соответствует требованию запускать приложение при запуске компьютера, и потому что программы инсталляции могут использовать интерфейсы API или технологию Windows Installer для безопасной остановки и запуска служб.
Каждый человек, потративший время на создание инсталляций, поймет, как сложно бывает пойти и объяснить разработчику, что приложение требует изменений в связи с предложениями такого вида, но сложности увеличиваются, если разработка и поведение приложения требуют взять инсталляцию в расчет.

Перезагрузки

Конечно, Вы можете никогда не перезагружать систему во время инсталляции, за исключением того случая, когда Вы абсолютно не можете без этого обойтись. Это один из случаев, когда Вам действительно поможет, если Вы знаете вашего пользователя. У всех нас есть персональные компьютеры дома и на работе, и возможно перезагрузка компьютера не такая уж большая задача. Однако такие компании как Unisys и другие предоставляют услуги на базе 32 процессорных систем, к которым подключены одновременно тысячи пользователей, и использование модели инсталляции для персонального компьютера здесь это плохая идея. Заказчики крупнейших систем требуют надежности класса мэйнфрейм (mainframe), и они не захотят прерывать работу их пользователей из-за инсталляции. Можно избежать частых перезагрузок посредством небольшой дополнительной работы, и если у вас есть пакет инсталляции Windows Installer для Windows 2000, он будет пытаться определить те файлы, которые в данный момент используются, и запросить у вас закрыть те приложения, которые их используют.
Я сталкивался с ситуацией, где программа установки запрашивала перезагрузку после создания служебных записей в реестре. В этом случае, разработчик не подозревал, что программы инсталляции могут устанавливать, запускать, и останавливать службы. Существовало ошибочное предположение, что перезагрузка необходима для запуска службы, первоначальный запуск которой установлен в автоматическом режиме (Automatic), при запуске после перезагрузки, но в реальных условиях, инсталляция может просто запустить ее.

Использование Windows Installer

Новая служба инсталляции Microsoft имеет непомерно высокие требования к обучению, и ее структура накладывает несколько ограничений на работу инсталляций. Она не имеет ничего похожего на более старую технологию установки, и вы должны изучать как минимум две большие новые области: Первое, это сама технология инсталляции, структура базы данных, таблицы, свойства, последовательности и правила обновления и переустановки. Второе, это инструмент, который вы используете для создания базы данных Windows Installer любой, и относительно простой, такой как инсталляция Microsoft Visual Studio, или как более полнофункциональные продукты, такие как InstallShield или Wise.

В мире Windows Installer, значение имеют эти несколько важнейших вопросов, которые вам необходимо осознавать:

  1. Инсталлятор Windows Installer это каркас с несколькими преимуществами для клиентских систем и коренной альтернативы более старым программам установки. Да, вы можете заниматься написанием кода и вставлять его в различных местах в последовательности инсталляции, но вам будет гораздо сложнее выполнять комплексные задачи во время установки. Если у вас есть сложная программа установки, используйте это как благоприятную возможность для ее пересоздания для соответствия требований структуры Windows Installer. Как и с любым другим подходом (framework) к программированию и разработке, для вас будет безопаснее следовать требованиям подхода, чем пытаться подогнать эти требования к неудобной разработке.
  2. Программа установки Windows Installer может выполнить такие действия, как откат всей инсталляции в случае, если в одной из ее частей произошла ошибка. Она включает функции самовосстановления, которая будет восстанавливать удаленные файлы и записи реестра. Вознаграждением для конечного пользователя будет более надежная инсталляция в случае, если разработчик следует рекомендациям Windows Installer.
  3. Программа инсталляции Windows Installer сокращает сложности во время установки как 32-разрядных программ, так и 64-разрядных. Для примера, записи реестра в базе данных Windows Installer по настоящему агностичны, они не имеют особенностей для 64-разрядных по сравнению с 32-разрядными. Различия между базами данных Windows Installer для 32-разрядных и 64-разрядных приложений возможно даже меньше, чем вы себе можете представить, особенно по отношению к записям реестра и данных регистрации компонент компонентно-объектной модели Microsoft (COM). В терминологии Windows Installer, регистрация компонент и другие записи реестра часто требуют от вас просто отметить компоненту как 64-разрядную, и для нее будут выполняться правильные операции.
  4. Технология Windows Installer будет лучше и в определении различий между случаями инсталляций "уровня компьютера (всех пользователей)" и "уровня пользователя", чем программы, сохраняющие свои собственные записи в реестре. Это вопрос становится более важных в системах Windows семейства NT (NT, Windows 2000, XP), которые становятся очень популярны на потребительском рынке. Идея общего компьютера в семейном окружении и быстрое переключение между пользователями (Fast User Switching) в Windows XP - о таких семейных системах, где каждый пользователь имеет собственное представление системы, и инсталляция для текущего пользователя - это как раз то, что делает эту идею работоспособной. Конечно, разработка приложения также должна следовать правилам размещения данных пользователей на уровне пользователя вместо уровня компьютера.
  5. Технология Windows Installer лучше для связанных общих компонент (side-by-side sharing), чем традиционные инструменты установки. Для примера, типовая серверная компонента, внутренняя по отношению к процессу, регистрируется самостоятельно, записывая весь путь к месту инсталляции в ключе реестра InProcServer32, тогда как Windows Installer запишет только имя файла, если вы правильно заполнили таблицу Class. Существует много большее число действий, которые вам необходимо выполнять, смотрите документацию библиотеки MSDN , для связанных общих компонент (side-by-side sharing), DLLRegisterServer, но вам не нужно беспокоиться обо всем, что касается записи абсолютных файловых путей кодом DLLRegisterServer.
  6. Объединяемые (merge) модули могут быть описаны, как эквиваленты объектам компонентной модели COM для Windows Installer. Они содержат файлы и функциональность, которые вы можете встраивать в основную программу инсталляции. Сервисное обновление SP5 пакета Visual Studio 6.0 поставляет более 40 объединяемых модулей для библиотек DLL и OCX, которые требуются для поддержки программ, разработанных в среде Visual Studio. Они становятся стандартным способом распространения конкретной функциональности при инсталляции.
  7. Инсталлятор Windows Installer версии 2.0 обладает явно выраженной поддержкой для установки сборок (assemblies) приложений, построенных по технологии .Net. Он содержит таблицы для инсталляции сборок и стандартные действия (standard actions) для публикации, как независимых сборок, так и общих. Связанные (side-by-side) сборки доступны в Windows XP. Как бета-релиз №2, для .Net Framework существует один из объединяемых модулей, который содержит всю поддержку .Net Framework. Этот объединяемый модуль не только включает файлы mscor*.dll, но также и компиляторы, требующиеся для выполнения компиляции во время выполнения для языков программирования C#, VB и IL. Использование технологии .Net COM Interop требует дополнительной работы по инсталляции, потому что выставление унаследованных серверных компонент COM к .Net (как и компонент .Net к унаследованным COM клиентам) требуют создания и инсталляции оболочки классов и информации реестра Windows. Например, ваши текущие клиенты COM ожидают данные регистрации компонент COM в реестре. Установка сервера .Net для его использования унаследованными клиентами COM поэтому требует инсталляции регистрационной информации, которую создает утилита .Net REGASM.EXE.

Протестируйте продукт, как установленный программой инсталляции

Это может быть очевидным руководством к действию, но иногда могут быть выявлены различия между приложением, установленным в системе разработчика и приложением, установленным на компьютере клиента. Здесь могут быть многочисленные причины, по которым тестирование должно быть выполнено с программой инсталляции: Во-первых, компьютеры разработчиков типично содержат каждую библиотеку DLL из мира библиотек Microsoft, таким образом, каждая библиотека DLL, используемая вашим приложением, наверняка виртуально уже существует в вашей системе разработки. Однако это не подходит для случая с системами ваших клиентов. Идеальный способ протестировать - это установить систему "с нуля" с установленной операционной системой Windows, и затем протестировать ваше приложение, отыскивая забытые библиотеки, которые требуются приложению для корректной работы. Процесс тестирования также становится необычным для тех приложений, которые хорошо работают в системах с Windows 2000, но не работают в Windows 9x, и часто задачей, решающей эту проблему, становится просто определить поддерживаемые библиотеки DLL, которые не устанавливаются с операционной системой.
Во-вторых, когда программы инсталляции создаются с использованием службы Windows Installer, наиболее общепринятым (и в практике, рекомендуемой Microsoft) считается хранить регистрационную информацию классов компонент COM в таблице базы данных, в файле MSI. Разработчик приложения, возможно, создавал приложение в системе, которая автоматически саморегистрирует сервера COM (это типично в среде Visual Studio), но это не тот способ, которым Windows Installer будет создавать записи реестра на компьютере вашего клиента. Код саморегистрации вашего COM сервера не будет выполняться в системе при установке в случае, если Windows Installer применяет записи регистрации из таблицы Class.
И, наконец, возможно вы устанавливаете службы, запуская командную строку -Service. Хотя вы можете продолжать установку таким способом, это делать не рекомендуется. Технология Windows Installer содержит специфическую поддержку для инсталляции и конфигурирования служб, а также управление другими службами, которые вам может потребоваться запустить или остановить. Эта возможность автоматически остановит или запустит все зависимые службы, если вы установите информацию о зависимости службы в базе данных Windows Installer. Как вы можете увидеть, среда разработки, вероятно, тестирует службы, установленные из командной строки с ключом -Service, но службы, устанавливаемые из базы данных Windows Installer , не устанавливаются этим способом, таким образом, вам нужно их тестировать с программой инсталляции.
Остерегайтесь обновлений файлов, содержащих данные пользователя
Иногда программа инсталляции будет устанавливать файлы с данными, предназначенными для использования пользователем. Это может быть файл базы данных Microsoft Access, предназначенный для дальнейшего обновления, или установленные файлы шаблонов, которые отредактирует пользователь. Однако программа установки по умолчанию удалит все файлы, которые были установлены при первоначальной инсталляции, так и файлы, подобные этим, будут потеряны при удалении программы инсталляции, что станет неприятным сюрпризом для ваших заказчиков, которые хотели сохранить свои данные. Аналогичные вопросы появляются и в сфере обновления файлов. Может оказаться неожиданно сложно обновить файл с данными во время инсталляции, если пользователь внес в него свои изменения, заменив таким образом дату последней модификации файла, возможно установив ее даже позднее, чем версия файла, который вы пытаетесь установить поверх него.

Центр обработки данных и драйверы устройств

Операционная система Microsoft Windows Datacenter является основной системой для сертифицированных конфигураций технических средств и программ - драйверов уровня ядра операционной системы. Эти конфигурации известных также под названием Сертификация центра обработки данных (Datacenter Certification). Конфигурации Центра обработки данных тестируются, и заказчики, работающие с сертифицированными конфигурациями имеют определенные гарантии поддержки. Установка не сертифицированной программы драйвера может нарушить эти гарантии для поддержки. С помощью утилит, которые предоставляются, заказчики могут проверить, остается ли их конфигурация все еще сертифицированной. Чтобы подчеркнуть очевидность этих мероприятий, напомним, что драйверы являются кодом, выполняющимся на уровне ядра операционной системы, и могут вывести ее из строя. Если ваше приложение использует драйверы, и вы предполагаете установить ее в системе Центра обработки данных, лучшая идея - это сначала обеспечить сертификацию для вашего драйвера, цифровую подпись и тестирование. Вам также стоит ожидать более строгих требований Microsoft к сертификации драйверов в будущем, включая прохождения ими процедуры тестирования и получения цифровой подписи.

Помните о безопасности

Программы установки обычно дают свободу для того, чтобы делать почти все в системе. Большинство из них требуют привилегий администратора для работы в Microsoft Windows NT/2000. Однако вы должны создавать инсталляцию, требующую привилегий администратора только в случае, если вы устанавливаете приложение для всех пользователей в этой системе. Если вы выполняете установку для текущего пользователя, вы должны спланировать инсталляцию без привилегий администратора, потому что вам не нужно изменять такие вещи, как службы Windows NT/2000 (которые в любом случае распространяются на уровне всей системы) или обновлять папки и ветки реестра, которые ограничены для использования только администраторами. Всегда, насколько это возможно, инсталляция должна соответствовать ожиданиям пользователя для общих компьютеров. Что пользователи, не являющиеся администраторами, смогут установить ваше приложение самостоятельно, без обращения в службу поддержки, и младшему не потребуется звать отца чтобы установить видеоигру, и наоборот.

Первые впечатления могут стать заключительными

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

Источники, использованные при написании статьи

Набор инструментов разработки программного обеспечения Windows Installer SDK является частью Platform SDK - вы найдете документацию и примеры программного кода на языках VBScript and C++.
http://www.installsite.org - это превосходный ресурс Интернет поддерживающий информацию по технологии инсталляции, трюках и инструментах.

Об авторе

Фил Вилсон является инженером по программному обеспечению корпорации Юнисис, его работа заключается в интегрировании технологии Windows Installer в проекты разработки программного обеспечения. Он кандидат наук в области химии университета Астон в Великобритании. Вы можете связаться с ним по электронной почте: phil.wilson@unisys.com.

Перевод на русский язык

Антон Спицын, MCP (Сертифицированный специалист Microsoft), участник форума InstallSite.org

 

English News Discussions Windows Installer Related Tools More Help InstallScript About InstallSite Shop Site Search
deutsch Neuigkeiten Diskussionsgruppen Windows Installer MSI FAQ Artikel     Shop Suche

Copyright © by InstallSite Stefan Krueger. All rights reserved. Legal information.
Impressum/Imprint Datenschutzerklärung/Privacy Policy
By using this site you agree to the license agreement. Webmaster contact.