Структура мастера установки

Question

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

Требования:

• Один исполняемый файл для развертывания, никакие другие файлы не связаны с ним.
• Должен поддерживать настраиваемые шаги конфигурации на каждой панели, которые в конце вносят свой вклад в сгенерированный файл конфигурации XML.
• Некоторые шаги могут быть пропущены в зависимости от выбора, сделанного в процессе установки.
• Должен поддерживать динамические экраны конфигурации на основе информации, полученной от классов в одной из моих библиотек.

Вот описание моего прототипа:

• Большая форма с кучей элементов управления Panel, каждый из которых представляет один «экран» мастера. Каждый назван соответствующим образом.
• Класс для каждого "экрана", производный от базового типа I, определенного. Я называю его конкретными методами (например, Enter, Back, Forward), когда происходят определенные события.
• Состояние сохраняется как Dictionary<string,object>, который передается на каждый экран. Последний экран (фактический экран «Установка ...») считывает конфигурацию из этого и выводит ее в файл XML.
• Код каждого экрана отвечает за обработку кнопок «Далее» и «Предыдущий», поэтому я могу контролировать, к чему он переходит, на основе настроек на текущем экране.
• В моей библиотеке хранится несколько модулей, которые предоставляют информацию о дополнительных шагах настройки, которые необходимо предпринять. Я реализую это с помощью рефлексии и автоматической генерации пользовательского интерфейса.
• Активы хранятся в ресурсах исполняемого файла.

Я не хочу использовать универсальный установочный пакет (например, InstallShield), потому что логика полностью настраивается и вызывает одну из моих библиотек классов. То, что я хотел бы знать, - я излагаю это действительно окольным способом? Существует ли более простой или более стандартный способ применения приложений в стиле мастера?

Answer 1

Вот краткий ответ:

Коммерческий инструмент идеально подходит для того, что вам нужно, поскольку он поддерживает как пользовательский интерфейс установки, так и динамические XML-файлы.Все остальное требует большой учебы и тяжелой работы.

И длинное объяснение:

Пользовательский интерфейс установки - непростая задача.Установщик Windows предлагает встроенные диалоговые окна и элементы управления, поэтому обычно это лучшее решение.Вы также можете попробовать проприетарный механизм установки, но вам нужно будет его изучить.

Вы также используете неправильный подход, пытаясь контролировать все с помощью пользовательского кода и классов.Большинство инструментов разработки настроек предоставляют прямую поддержку для обработки файлов пользовательского интерфейса и XML-файлов установки.Зачем пытаться заново изобрести колесо?

Так что вам, в основном, нужно найти инструмент для создания настроек, который лучше всего подходит для вас.Вот общий список: http://en.wikipedia.org/wiki/List_of_installation_software

Инструменты основаны на MSI или являются проприетарными.Лично я предпочитаю установщик Windows (пакеты MSI).

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

Answer 2

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

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

Установщик Windows предоставляет несколько загадочный API для создания пакетов, но вы также можете использовать затем открытый исходный код Набор инструментов WiX , который является довольно мощным или любым коммерческим установщиком, таким как InstallShield .

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

Установщик Windows на самом деле достаточно мощный.Вы не предоставили никакой конкретной информации о «пользовательских вещах», которые вам нужно сделать, но, возможно, у установщика Windows уже есть таблица для этого?

Answer 3

Используйте InstallShield или установщик MSI.Шутки в сторону.В дополнение к возможности поддержки всех видов настраиваемой логики (включая указанный вами код), универсальные мастера установки выполняют такие вещи, о которых вы даже не задумывались, например, например, перечисление установленного приложения в «Программы и компоненты» и выполнение восстановительных установок/uninstalls.

Учитывая уровень настраиваемой вами логики, я бы выбрал последнюю версию установщика InstallShield;проект VS Install строится в довольно простом диалоговом наборе.

РЕДАКТИРОВАТЬ: Достаточно справедливо, был в этом положении раньше.

Я все равно НАСТОЯТЕЛЬНО рекомендую использовать любые доступные вам инструменты инсталлятора, такие какПроект установки VS по причинам, которые я изложил выше;пакеты установки делают то, о чем вы даже не задумывались в своем дизайне, и вы получаете все это бесплатно.

Вместо того, чтобы использовать эту логику для настройки вашего XML-файла конфигурации в установщике, как насчет размещения этого?в вашем исполняемом файле, как "мастер настройки запуска", который пользователь увидит, когда он запустит приложение после его установки?Это не должно быть слишком неприятным для ваших пользователей, и оно должно работать хорошо, если реальное приложение также является приложением WinForms (даже если это не так; вы можете скомпилировать конфигуратор в другое приложение и запустить свое основное приложение).конфигуратор, если у него нет файла XML).

Answer 4

Один исполняемый файл для развертывания, никакие другие файлы не связаны с ним.

Это может вас заинтересовать: http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx