Средства создания дистрибутивов
Часть 1. Простые Windows-приложения
Об особенностях некоторых отечественных продуктов
Что делает процедура установки настольного приложения
Несложное настольное Windows-приложение
Приложение, хранящее настройки в ini-файлах
Приложение, использующее библиотеки общего назначения
Приложение, содержащее COM-серверы
Несколько слов о технологиях и инструментах
Об особенностях некоторых отечественных продуктов
оворя
о разработке приложений, многие из нас в первую очередь имеют в виду собственно
создание кода, в лучшем случае — проектирование приложений и данных. Подобного
подхода к созданию приложений нередко придерживаются не только начинающие программисты,
но и многие опытные разработчики и аналитики. Документация, изобилующая программистским
жаргоном и грамматическими ошибками, приложения без файлов справочной системы,
инструкции по установке продукта, состоящие из громадного количества пунктов
типа «создать такую-то переменную окружения» или «в таком-то ключе реестра изменить
такое-то значение» и вызывающие справедливое негодование системных администраторов,
которым предстоит выполнить эту инструкцию десятки раз, отсутствие корректного
списка системных требований, предъявляемых приложением, — вот далеко не полный
перечень, так сказать, «особенностей» многих российских разработок, порой сводящих
к нулю немалые усилия, связанные с качественным созданием кода самих приложений.
Все это нередко снижает желание потенциального потребителя приобретать или заказывать
подобные приложения даже при значительных маркетинговых усилиях компании-разработчика,
вследствие чего рынок тех или иных видов приложений завоевывается менее качественными
и нередко технологически устаревшими, но при этом отлично «упакованными» западными
разработками, активно продвигаемыми отечественными реселлерами и системными
интеграторами.
На наш взгляд, причин такого положения дел две. Первая из них заключается в неправильной организации работы, когда на документирование, создание справочной системы и дистрибутива не выделяется достаточно времени и ресурсов. Вторая причина, возможно, кроется в неинформированности руководителей проектов и разработчиков о так называемых дополнительных продуктах, способных облегчить превращение набора исполняемых файлов в такой товар, на который не жалко потратить деньги. Именно поэтому мы планируем опубликовать в нашем журнале несколько статей, посвященных перечисленным выше «вспомогательным» этапам разработки приложений.
Настоящая статья (и несколько последующих) будут посвящены этапу создания дистрибутивов приложений. На этот этап, как правило, просто не хватает времени — зачастую последние найденные при тестировании ошибки в приложении исправляются чуть ли не прямо перед сдачей проекта. Однако, как показывает практика, создание качественного дистрибутива требует определенных усилий, а его тестирование в некоторых случаях может оказаться отнюдь не менее сложным, чем тестирование собственно поставляемого приложения.
Сегодня мы рассмотрим простейшие задачи, связанные с созданием дистрибутивов простых Windows-приложений, а в последующих статьях поговорим о создании дистрибутивов серверных приложений, Web-приложений, о включении в состав дистрибутива продуктов других производителей и о некоторых вопросах, связанных с внедрением и обновлением приложений.
 |
|
Что делает процедура установки настольного приложения
то
должна делать процедура установки приложений? В первую очередь, конечно, копировать
файлы на жесткий диск конечного пользователя. А еще создавать ярлыки на рабочем
столе и в главном меню, нужные приложению ключи реестра, регистрировать COM-серверы,
если таковые входят в состав продукта, и многое другое. Давайте рассмотрим по
порядку, что именно может потребоваться при установке продукта.
Несложное настольное Windows-приложение
Как правило, процедура установки настольного Windows-приложения должна:
- позволить конечному пользователю выбрать каталог для установки продукта;
- в ряде случаев позволить пользователю установить продукт частично;
- скопировать файлы в указанный пользователем каталог;
- создать программную группу в меню Start и, возможно, разместить пиктограмму приложения на рабочем столе;
- в ряде случаев добавить в реестр некоторые ключи, изменить некоторые переменные окружения, а также разместить некоторые файлы в системном каталоге Windows.
Кроме того, помимо процедуры установки, пользователю должна быть доступна и процедура полного удаления приложения, которая не только стирает файлы, скопированные в процессе установки продукта, но и ликвидирует ключи реестра и иные изменения в операционной системе, созданные процедурой установки.
Приложение, хранящее настройки в ini-файлах
Если приложение обращается в процессе работы к ini-файлам, то в процессе установки приложения может потребоваться их модификация. Типичный пример — хранение в ini-файле пути к каталогу, в котором расположены используемые приложением данные. Если пользователь может выбирать местоположение этого каталога, то совершенно очевидно, что в ini-файл в процессе установки приложения должны быть внесены соответствующие изменения.
Приложение, использующее библиотеки общего назначения
Для начала — одно замечание, касающееся в основном начинающих разработчиков. Если на вашем компьютере имеются какие-то библиотеки, из этого вовсе не следует, что они есть и у конечного пользователя (например, к таковым относятся библиотеки, входящие в состав средства разработки), поэтому, создавая дистрибутив приложения, следует проанализировать это приложение на предмет обращения к подобным библиотекам, а сам дистрибутив протестировать на чистой (то есть не содержащей никаких приложений) версии операционной системы, для которой предназначено приложение. Можно провести такое тестирование и с помощью какой-либо виртуальной машины, управляемой одним из предназначенных для этой цели продуктов Microsoft или VMware. А самое главное — нужно иметь право на поставку этих библиотек в составе своего решения.
Если в состав приложения входят библиотеки общего назначения (например, библиотеки, содержащие наборы элементов управления или библиотеки, реализующие тот или иной механизм доступа к данным), необходимо позаботиться о том, чтобы при установке продукта не происходило замены новых версий библиотек более старыми версиями. Казалось бы, используя последние версии тех или иных библиотек, вы застрахованы от неприятностей, связанных с подобными событиями, однако это не более чем иллюзия — через пару лет эти версии уже не будут последними, а ваше приложение, возможно, все еще будет продаваться или хотя бы использоваться и устанавливаться.
В качестве иллюстрации приведем весьма показательный пример. В одной европейской стране в 1997 году выпустили электронную версию телефонного справочника этой страны, написанную на Delphi 2 и содержащую первую 32-разрядную версию библиотек универсального механизма доступа к данным Borland Database Engine, которые вместе с файлом, хранящим настройки для этих библиотек, просто копировались при установке продукта в некий предназначенный для них стандартный каталог. Тираж диска был весьма велик, справочник продавался в течение длительного срока, и за это время появились новые продукты, созданные с помощью более поздних версий того же средства разработки. И тогда у авторов этих самых новых продуктов начались неприятности — пользователи, уже эксплуатировавшие их продукты, устанавливали на свои компьютеры тот самый телефонный справочник, более старые версии библиотек заменяли собой более новые, файл настроек тоже оказывался совершенно другим, а приложение, использовавшее более новые версии библиотек, становилось неработоспособным. Цитировать, что по поводу авторов телефонного справочника говорили разработчики, выслушивавшие претензии от своих клиентов, видимо, не стоит… Коллеги, давайте не будем создавать друг другу проблем!
Приложение, содержащее COM-серверы
COM-приложения, написанные в строгом соответствии с правилами их создания, обычно не столь чувствительны к проблемам, связанным с заменой новых версий библиотек более старыми. Однако и о них следует заботиться при создании процедуры установки приложения.
Если в состав приложения входят COM-серверы (например, элементы управления ActiveX), то они должны быть зарегистрированы в системном реестре — иначе в процессе выполнения приложения операционная система не сможет их найти. Соответственно и процедура удаления продукта должна перед удалением входящих в его состав файлов дерегистрировать эти COM-серверы, если только они не используются еще каким-либо другим приложением.
Обновления и дополнения
Ни одно приложение никогда не бывает настолько хорошим, что его совсем не захочется улучшить. Нередко это означает, что потребуется создавать дистрибутив второй, третьей и иных последующих версий продукта. Своего рода правилом хорошего тона (не являющимся, впрочем, категорически обязательным к применению) в этом случае является предоставление пользователю возможности установить новую версию продукта, не удаляя старую.
|
|
Несколько слов о технологиях и инструментах
адача
создания дистрибутивов Windows-приложений является совершенно типовой и отнюдь
не новой. А это, в свою очередь, означает, что для ее решения уже созданы разнообразные
технологии и инструменты.
Технологии
Для создания дистрибутивов приложений и обновлений к ним производители платформ обычно создают прикладные программные интерфейсы. В случае Windows таковыми являются Setup API (данный программный интерфейс применялся для всех 32-разрядных версий Windows, кроме Windows Server 2003) и Microsoft Windows Installer, доступный в составе всех имеющихся 32-разрядных версий Windows или пакетов обновления к ним. Microsoft Windows Installer позволяет осуществлять очень много интересных операций, например рекламировать компоненты приложения без их установки, устанавливать части продукта по требованию при обращении к ним, создавать пакеты обновления, которые могут быть использованы средствами управления приложениями для массовых обновлений программного обеспечения многих рабочих станций.
Инструменты
Одних только API для комфортной работы, связанной с созданием инсталляционного приложения, обычно недостаточно. Однако существуют инструменты, которые снабжают Microsoft Windows Installer приемлемым пользовательским интерфейсом и во многих случаях избавляют разработчиков от необходимости создавать код инсталляционного приложения. Сама компания Microsoft рекомендует продукты трех производителей: InstallShield, OnDemand Software и Wise Solutions, каждый из которых производит широкий спектр продуктов, предназначенных для создания различных типов инсталляционных приложений, и потому продукты этих компаний еще не раз будут упомянуты в последующих статьях. Однако сегодня в первую очередь хотелось бы остановиться на простейших способах решения задач, перечисленных в настоящей статье (то есть связанных с созданием дистрибутивов простейших Windows-приложений).
Как правило, эти задачи решаются с помощью простейших версий инструментов вышеназванных компаний. Нередко в состав различных средств разработки и некоторых других продуктов входят инструменты создания дистрибутивов, адаптированные для данного средства разработки, и лидером в области создания адаптированных версий своих инструментов и включения их в состав продуктов других компаний является, пожалуй, компания InstallShield со своим продуктом InstallShield Express Limited Edition.
InstallShield Express Limited Edition обладает набором возможностей, помогающих довольно успешно решить задачи создания дистрибутивов несложных приложений. Этот продукт позволяет проверять, соответствует ли операционная система требованиям, предъявляемым устанавливаемым приложением, копировать файлы приложения в каталоги, указанные пользователем, создавать пиктограммы и программные группы в меню Start и на рабочем столе, предоставлять пользователю возможность выбрать, какие части продукта устанавливать, создавать пакеты обновлений установленных ранее приложений.
Данный продукт позволяет вносить изменения в реестр и ini-файлы, создавать переменные окружения, определять, какие из библиотек общего назначения следует включить в состав дистрибутива приложения, связывать указанные автором дистрибутива расширения файлов с устанавливаемыми приложениями. Дистрибутив может быть создан в виде образа CD, DVD, а также в виде одного-единственного исполняемого файла setup.exe.
Кроме того, редакции InstallShield, входящие в состав средств разработки, как правило, позволяют включать в состав приложения библиотеки и иные компоненты, характерные для приложений, созданных с помощью указанного средства разработки, — такие как runtime-библиотеки, библиотеки, реализующие механизмы доступа к данным, элементы управления ActiveX. И конечно, редакции InstallShield, входящие в состав средств разработки, позволяют регистрировать COM-серверы (если таковые можно создавать с помощью данного средства разработки).
При всех достоинствах данного продукта он имеет весьма серьезные ограничения. Так, создать качественный дистрибутив Web-приложения с помощью этого продукта довольно затруднительно, поскольку он не умеет создавать ни каталоги с нужными свойствами, ни виртуальные сайты на Web-серверах, равно как и присваивать пользователям различные права на эти (или другие) каталоги. Встроить в инсталляционное приложение вызов другого приложения (например, процедуры установки другого продукта) с помощью подобной версии InstallShield Express тоже не удастся, как и зарегистрировать службу операционной системы. В подавляющем большинстве случаев нельзя создать и руcскоязычную версию дистрибутива (а потому не стоит использовать эту версию InstallShield Express для «упаковки» русскоязычных коробочных продуктов). Но для создания развертываемого на большом количестве рабочих станций дистрибутива клиентской части приложения, обращающегося к какой-нибудь серверной СУБД или иному серверному приложению, либо несложного настольного приложения данный продукт вполне пригоден, а потратив некоторое, относительно небольшое количество усилий на работу с ним, вы избавите системных администраторов, устанавливающих ваш продукт на рабочие станции пользователей, от многих проблем.
|
|
Заключение
так,
вы, наверное, уже поняли, что создание процедуры установки настольного приложения
— вещь не такая уж и сложная. Современные средства разработки обычно содержат
в своем составе инструменты создания дистрибутивов, решающие все или подавляющее
большинство перечисленных выше задач, а сами дистрибутивы подобного класса достаточно
просты в тестировании, и потому самой большой сложностью в данной ситуации может
оказаться создание русскоязычной версии дистрибутива.
Создание дистрибутивов Web-приложений и приложений, в состав которых входят службы операционной системы или встроенные продукты сторонних производителей, а также иных серверных приложений, представляет собой более сложную задачу, и об этом мы поговорим в следующем номере нашего журнала.
