Сообщений 7 
Оценка 520
[+1/-0]
Оценить 
| Сообщений 7 Оценка 520
[+1/-0]
Оценить
|
Вы привыкли к мысли, что программа это только «экзэшник»? Должен вас разочаровать. Случай когда исполняемый файл ни от чего не зависит — редкий, можно сказать, раритетный. Скорее всего он зависит, и очень жестко — от своего окружения:
По-видимому, в жизни часто встречается следующий сценарий. Программист сосредоточен на создании самого приложения — интерфейса и функциональности. Проблема работы в целевых конфигурациях решается «по факту». Программа уже дописана или частично написана, когда выясняется (обычно в ходе показа на компьютере начальника либо заказчика), что программа падает со страшным криком. Далее обычно следует серия экспериментов, в результате которых программу заставляют работать (обычно путем случайного или целенаправленного подбора условий удачной установки), либо дело заканчивается провалом и на форумах появляется крик души вида «Я перенес программу на другой компьютер, она не запускается!».
Как это, в принципе, должно делаться «по уму».
Сначала немного о терминологии, для определенности. Средство создания дистрибутивов мы будем называть инсталлятор. Под словом дистрибутив понимаем распространяемые файлы программы — обычно это Setup.exe плюс, возможно, еще несколько файлов. Т.е., по сути, дистрибутив — это то что получается на выходе инсталлятора. Программа установки приложения — это программа, которая собственно и выполняет все действия по установке. Обычно она состоит из двух частей: bootstrapper (Setup.exe), который выполняет подготовительные действия (например, разархивирует файлы приложения и файлы самой программы установки) и запускает вторую часть — installation engine. Программа установки либо использует свой собственный installation engine, либо пользуется услугами сервиса Windows Installer. Installation engine выполняет всю основную работу: взаимодействует с пользователем через GUI, создает/удаляет папки и ключи реестра, копирует файлы, регистрирует компоненты и т.д.
Подробнее о терминологии и основах см. Setup is... (статья в блоге Rob Mensching).
Первое. На этапе проектирования программы — определяется целевая аудитория. По ней определяется — в каких версиях операционной системы (имеется в виду Windows) должна работать программа. В частности, задайте себе вопросы: должна ли программа работать под Windows 98? а 98SE? Windows ME? Нужно ли обеспечивать работу программы под Windows NT? Знаете ли вы, сколько ваших потенциальных пользователей используют Windows версии ниже XP? Имеет ли смысл от них отказаться?
Второе. На том же этапе определяется — каким образом будет распространятся программа — на дискете, на CD (какого объема?), DVD, будут ли программу скачивать с сайта, какой объем готовы скачать пользователи. Это должно дать вам оценку — в какой объем дистрибутива нужно уложиться.
Далее. В ходе разработки на некотором этапе выполняется анализ — какие компоненты и библиотеки — системные, поставляемые со средой разработки а также сторонние (third party) вы используете, и каких версий. Имеются автоматические средства, позволяющие определить зависимости программы. Для VB6 в этих целях можно использовать Package & Deployment Wizard (PDW), для C/C++ — утилиту Depends. После того как полный и точный список библиотек получен — нужно выяснить, в состав каких инсталляционных пакетов входят эти библиотеки, для каких версий ОС и в каком виде они доступны, какие для них имеются последние заплатки (patches) и пакеты обновлений (service packs). Важно также найти способ определения — установлен ли уже в системе данный компонент или нет. В результате такого анализа должен получиться список компонентов или даже таблица, по которой легко определить — в такой-то версии системы нужно ставить вот такие-то пакеты.
| ПРИМЕЧАНИЕ Ключевой момент: нужно точно знать условия, в которых работает программа, а не подбирать их «методом научного тыка». |
По полученному списку пакетов уже можно определить реальные размеры дистрибутива — это (примерно) объем устанавливаемых пакетов + объем самой программы и ее данных + программа установки, минус сжатие при упаковке в готовый инсталляционный пакет.
Теперь у нас уже должно быть: список файлов, входящих в дистрибутив и знание о том что нужно делать на этапе установки (что определять в целевой системе, какие библиотеки устанавливать и куда, как их регистрировать, что куда копировать).
Исходя из сложности процесса установки и требований отдельных компонентов — выбираем инсталлятор, описываем в нем процесс установки/удаления программы и настраиваем сборку дистрибутива.
И наконец, необходимо выполнить проверку работы всех основных функций программы под всеми целевыми версиями ОС. Обычно это делается с помощью виртуальных машин — таких программ как VirtualPC или VMWare, на заранее подготовленных образах виртуальных машин.
Описанный процесс анализа и реализации может начинаться на ранних стадиях разработки и дополняться инкрементально — по мере добавления в программу новых компонентов и подключения библиотек. Либо, этот процесс может быть выполнен в самом конце разработки (в этом случае выше риск не уложиться в заданный объем дистрибутива).
Сборку дистрибутива можно выполнять вручную — запустить из среды разработки сборку приложения, скопировать нужные файлы, запустить инсталлятор, собрать дистрибутив. Проблема в том, что этот процесс должен выполняться не один, не два и даже не десяток раз. Каждая ошибка, выявленная в ходе установки и тестирования, требует повторной пересборки проекта и дистрибутива. Этот процесс может выполняться сотни раз. Так что без автоматизации тут не обойтись.
Все используемые средства разработки, в т.ч. среда разработки (IDE) и инсталлятор, должны обеспечивать возможность выполнения действий по компиляции и сборке с командной строки. Иначе эти средства просто не подходят для использования в разработке мало-мальски серьезного продукта.
Существует целый класс систем, позволяющих выполнять автоматизацию задач по сборке приложения. К ним относятся: nmake в Visual Studio 6.0, Ant, NAnt для .NET, MSBuild.
См. также: Pragmatic Project Automation: How To Build, Deploy, and Monitor Java Applications by Mike Clark (книга) — несмотря на слово Java в названии, все используемые подходы с легкостью переносятся на платформу .NET
Если ваша программа довольно проста, прежде чем использовать инсталлятор, подумайте — возможно, будет лучше выбрать более простые способы распространения? Захотят ли ваши пользователи проходить мастер установки с очевидными вопросами и очевидными ответами?
Существуют архиваторы и отдельные утилиты, позволяющие создавать самораспаковывающиеся (self-extracting, SFX) архивы, назначение которых — держать файлы в сжатом виде, но избавить пользователя от необходимости искать утилиту распаковки. Из подобных инструментов можно назвать WinRAR (Shareware, $30) и 7-zip. Они также позволяют создать такой SFX, который после распаковки файлов запустит заданный файл.
См. также: Автоматическая установка. Создание SFX архива (статья)
По словам Microsoft, одним из преимуществ использования .NET является возможность использования для многих приложений простейшего способа распространения — копирования файлов через XCOPY. Не требуется регистрации компонентов (как это требовалось для COM/DCOM), не требуется регистрации общих библиотек — по умолчанию программа будет использовать те сборки, которые лежат вместе с исполняемым модулем. Это прекрасный способ распространения для утилит: не нужно проходить мастер установки с очевидными вопросами и очевидными ответами; если программа больше не нужна — просто удалите папку программы.
См. также: MSDN: Determining When to Use Windows Installer Versus XCOPY
Стоит также упомянуть ClickOnce — новую технологию распространения WinForms-приложений от Microsoft, являющуюся составной частью концепции Smart Client. Поддержка ClickOnce встроена в Visual Studio 2005.
Один из возможных сценариев, реализуемых с использованием ClickOnce: пользователь щелкает по ссылке на веб-странице, скачивается «Deployment Manifest» (XML-файл с расширением .deploy), содержащий указание на текущую версию приложения. Это приводит к скачиванию еще одного манифеста, описывающего состав приложения. По информации из этих двух файлов скачиваются необходимые сборки, а также производятся действия — такие как создание ярлыков в меню «Пуск» и создание в реестре ключа для апплета «Установка и удаление программ».
См. также: Deploying Windows Forms Applications with ClickOnce
Но если этих возможностей для распространения вашей программы недостаточно — придется использовать что-либо посерьезнее.
Средства создания дистрибутивов (для простоты — инсталляторы) обычно решают следующие задачи:
Стоит особо остановиться на функциях, выполняемых bootstrapper. Эта часть программы установки запускается первой и ее задача — подготовить все необходимое для работы installation engine. В частности, в случае использования Windows Installer, bootstrapper обеспечивает установку или обновление Windows Installer до требуемой версии.
Иногда на bootstrapper также ложится задача установки системных компонент, необходимых для работы приложения — например, установка .NET Framework. В этом случае bootstrapper «распухает» и часто имеет смысл выделить его в отдельный исполняемый модуль, который выполнит необходимые проверки, установит недостающие компоненты, а затем, когда система уже полностью подготовлена — запустит основную программу установки приложения. Таким образом действительно за один клик происходит вся установка приложения.
См. также:
Все инсталляторы можно разделить на две большие группы:
Если вы спросите на одном из программистских форумов — какой инсталлятор выбрать, то наверняка вы получите в ответ «золотую пятерку»: InstallShield, NSIS, InnoSetup, WiX, Wise. Это инсталляторы «общего назначения». Кроме них существуют инсталляторы «специализированные» — для своей платформы, среды разработки или языка. Например, Package & Deployment Wizard (PDW) для VB6 или Visual Studio Installer в Visual Studio 6.0.
Опять же, судя по обсуждениям на форумах, критериями выбора инсталлятора являются: простота в использовании, поддержка русского языка или интернациональность, наличие гибкой настройки набора шагов мастера установки, возможность задания скриптов для дополнительных действий, возможность запуска внешних утилит и вызова функций из DLL, лицензия, бесплатность, наличие исходного кода, поддержка Windows Installer, удобство (субъективный критерий, включающий все остальное: например, для одних удобством является возможность сборки дистрибутива с командной строки, для других — наличие развитого GUI).
В свете этого, рассмотрим основные используемые инструменты:
| Продукт | Цена / лицензия | Тип | Простота (1) |
|---|---|---|---|
| InnoSetup | бесплатен | Скриптовый | ***** |
| Nullsoft Scriptable Install System (NSIS) | бесплатен | Скриптовый | *** |
| InstallShield 11 | от $449 до $2499 | Windows Installer (2) | **** |
| Windows Installer XML (WiX) toolset | бесплатен / CPL | Windows Installer | ** |
| Wise for Windows Installer 6 | от $449 до $1999 | Windows Installer | ? |
| Wise Installation System | от $449 до $999 | Скриптовый | ? |
Примечания:
Более подробно остановимся на наиболее популярных бесплатных инструментах.
Сайт: http://www.jrsoftware.org/isinfo.php
Цена: Полностью бесплатен (в т.ч. для коммерческого использования), имеются исходники (Delphi).
Базовый вариант скрипта инсталляции легко создать с помощью мастера (Script Wizard).
Скрипт имеет декларативный стиль описания, сходный со стилем INI-файлов. Есть возможность использования пользовательских скриптов (секция [code]), по синтаксису сходных с Object Pascal:
| ПРИМЕЧАНИЕ The scripting engine used by Inno Setup is RemObjects Pascal Script by Carlo Kok. Like Inno Setup, RemObjects Pascal Script is freely available and comes with source. See http://www.remobjects.com/?ps for more information. |
InnoSetup берет своей простотой. Его стоит порекомендовать разработчикам, использующим Delphi — и скрипты можно писать на привычном языке, и в исходники инструмента полезно заглянуть.
См. также:
Сайт: http://nsis.sourceforge.net/
Цена: Полностью бесплатен для любого использования, есть исходники (С++).
NSIS был создан в Nullsoft в качестве инструмента создания дистрибутивов для проекта WinAMP. Впоследствии NSIS был выделен в отдельный проект с открытым исходным кодом. Первая версия NSIS увидела свет летом 2000 года. С тех пор он подрос до версии 2.10 (релиз от 4.10.2005).
Исходный файл NSIS — это скрипт, в котором встречаются как декларативные описания, так и команды на выполнение действий. Язык скрипта чем-то походит на язык ассемблера: тоже регистры, команды, метки, стек. При этом есть как низкоуровневые команды — например: Push/Pop (работа со стеком), StrCmp/IntCmp (сравнение и переход), Call/GoTo — так и высокоуровневые, например: ReadRegStr (прочитать строку из реестра), RegDLL (зарегистрировать COM DLL), RMDir (удалить папку).
В отличие от InnoSetup, в котором текст секции [code] парсится уже во время работы программы установки, NSIS использует другой подход: весь скрипт компилируется в машинные команды на этапе сборки дистрибутива.
В NSIS есть возможность использования подпрограмм (функций), функции вызываются друг из друга при помощи инструкции Call. Препроцессор позволяет включать одни скрипты в другие с помощью директивы !include, а также создавать макросы.
Кроме того, есть возможность использования плагинов (внешних DLL), из которых можно вызывать функции во время работы программы установки. В составе пакета NSIS сейчас предлагается 15 стандартных плагинов. Плагин InstallOptions позволяет описывать дополнительные шаги мастера установки, с собственным набором контролов и поведением. Плагин LangDLL обеспечивает многоязыковую поддержку (в дистрибутив включены файлы для 49-ти языков). Плагин NSISdl предоставляет возможность загрузки нужных файлов по HTTP. Если возможностей стандартных плагинов недостаточно — нет ничего трудного в том чтобы написать свой.
Дистрибутивы, построенные с помощью NSIS первых версий были легко узнаваемы по характерному стилю интерфейса. Теперь этот интерфейс в NSIS называется Default, а кроме него появились Tiny и Modern. Стиль Modern копирует устоявшийся стиль мастера установки Windows XP.
В составе пакета имеется подробное руководство — по использованию NSIS, его скриптовому языку и препроцессору. В частности, в руководство входят примеры макросов: «Get Windows version», «Is .NET Framework installed?», и др.
См. также:
Сайт: http://wix.sourceforge.net/
Лицензия: CPL (Common Public License), есть исходники (C++, C#).
В апреле 2004 компания Microsoft выпустила Windows Installer XML под лицензией CPL и разместила его на сайте SourceForge. WiX стал первым проектом, выпущеным компанией под открытой лицензией.
WiX — это набор консольных утилит, позволяющих создавать инсталляционные пакеты (точнее, базы данных для Windows Installer — .MSI и .MSM) на основе декларативных XML-описаний. Инструменты, входящие в WiX, работают с командной строки.
В состав WiX входят четыре утилиты:
Для удобства работы с WiX предлагается Votive — Add-In к VS.NET, позволяющий создать новый WiX-проект (File | New | Project, WiX Projects), и компилировать WiX-проект непосредственно из IDE.
До появления WiX, с базами данных Windows Installer можно было оперировать только средствами Windows Installer SDK и с помощью редактора Orca. По сравнению с этими средствами, WiX представляет из себя несомненный шаг вперед: теперь все что нужно описывается в виде XML-файла, а сборка дистрибутива легко автоматизируется.
WiX позволяет использовать все возможности Windows Installer, но будьте готовы к тому, что при работе с WiX от вас потребуются серьезные знания самого Windows Installer.
См. также:
| Сообщений 7 Оценка 520
[+1/-0]
Оценить
|