Сам устанавливание приложения или отдельного установщика?
4 ответа
Существуют за и против к обоим подходам:
Наличие установщика является надлежащим способом установить необходимые компоненты системы, как драйверы, библиотеки, COM-компоненты и так далее. Так как для многих из этих операций нужны поднятые полномочия, установка может быть выполнена администратором, в то время как приложение может использоваться всеми пользователями.
Могут на самом деле быть требования для scriptable процесса установки в корпоративных средах.
Не наличие установщика открывает путь к портативным приложениям. Если программа имеет все в каталоге, то это может просто быть скопировано в карту с интерфейсом USB и выполняется в любой системе. Это не может, конечно, иметь смысла для Вашего конкретного вида приложения, но это - чтобы Вы решили.
Я не уверен, что проблема о поврежденных настройках действительно важна здесь. Если настройки повреждаются (почему?) - как приложение должно знать, что делать с этим? OTOH, которые установщик может, конечно, также быть записан в не вслепую, перезаписывают любые старые настройки. Все это зависит...
Править: Вы пишете в своем комментарии:
Даже портативные приложения требуют определенной конфигурации/настроек, Не, она лучше, чтобы иметь главное приложение проверяет, что настройки допустимый/существуют на каждом запуске и только предлагают пользователю при необходимости.
и снова, это действительно зависит от Ваших потребностей. Существуют различные типы параметров конфигурации или предпочтений, и необходимо решить индивидуально:
Параметры конфигурации в расчете на пользователя будут отсутствовать, если приложение будет запущено впервые текущим пользователем. Может быть полезно показать сообщение, что это отсутствует, и как создать его. Например, в FlameRobin (программа администрирования баз данных для Firebird) у нас есть сообщение, которое показывают, когда никакие зарегистрированные серверы и базы данных не найдены на запуске программы, и как зарегистрировать их.
Настройки в расчете на пользователя для поведения UI будут также отсутствовать, но существуют значения по умолчанию для них. Пользователь получит поведение по умолчанию приложения и может позже изменить вещи в диалоговом окне опции. С тех пор лучше минимизировать количество таких настроек, и так как значения по умолчанию должны быть тем, что большинство пользователей ожидает или что работы лучше всего в общем случае, нет также никакой потребности побеспокоить пользователя при запуске программы.
Некоторая конфигурация может быть не в расчете на пользователя, но на программу. Это обычно хранится в месте, где типичные пользователи не имеют никакого доступа для записи, таким образом проверяя на это и предлагают пользователю входить, это не действительно полезно. То, что могло быть сделано, должно запустить внешнюю программу, прося у типичного пользователя учетную запись с необходимыми полномочиями и ее паролем.
Движение с отдельным установщиком является "лучшим" путем с моей точки зрения. Создание самоустановки приложения не только добавляет дополнительную рабочую нагрузку к самому приложению, это также "работает вокруг" любой системы установщика базовой операционной системы (как MSI на окнах).
И если приложение повреждает свои настройки со временем, оно повреждается и потребность, которая будет зафиксирована. Как поврежденные настройки должны быть обработаны самоустановщиком? Просто перезапишите его со значениями по умолчанию? Пользователи будут раздражаться тем также, также - их для запуска отдельного установщика и выбора опции "восстановления" сделает это, по крайней мере, более прозрачным.
Я рекомендовал бы отдельный установщик, который может сделать следующее:
- Установите новую установку
- Восстановите существующую установку
- Удалите существующую установку
Причина, которую я рекомендую этим опциям, состоит в том потому что, именно это я приехал для ожидания для установщиков в средах Windows.
Причины я рекомендую сепарационную установку и прикладную логику в две других области приложений:
- Могут быть конфликты между зависимостями, используемыми используемый установщиком и приложением.
- Я хочу быть уверенным, что мои команды непреднамеренно не используют классы в зависимостях от платформы установщика при разработке приложения.
Спасибо за Вашу обратную связь. Я начинаю думать, что что-то вдоль этих строк было бы хорошим подходом компромисса:
- Выберите сам подход установщика путем создания компонента установщика (библиотека классов), на которую ссылается главное приложение.
- Этот компонент является базовой частью приложения и ответственен за обеспечение всей конфигурации/настроек, существуют и допустимы.
- Главное приложение. исполняемый файл, на каждом выполнении, просит, чтобы этот компонент проверил existance/validity настроек и только предложил пользователю при необходимости. Это могло быть легко сделано удобным для пользователя способом путем группировки всех проблем установки, и представление их в единственном GUI (избегает последовательности раздражающих диалогов).
- Для интеграции ОС компонент установщика (в случае Windows) гарантирует, что запись добавляется к, "Добавьте, Удаляют Программы" список для приложения, а также любая другая ОС потребовала конвенций.
- В рамках приложения стандартный экран опций/настроек также обеспечивается компонентом установщика. Это старается не копировать код управления настройками.
Я задал этот вопрос, потому что я встретил многих нетехнических пользователей, которые спрашивают, почему они не могут просто скопировать приложение от одного компьютера до другого, они могут сделать это со своими данными (например, фотографии, документы и т.д.). Это - чрезвычайно допустимый вопрос, в особенности для ориентированных настольных приложений GUI.
Отдельные установщики являются, конечно, "способом, которым это много лет делалось" в Windows. Для драйверов/компонентов системы очевидно, они часто - необходимость. Но поскольку настольный GUI разрабатывают приложения, я не полагаю, что они являются лучшими с точки зрения простоты и realiability для пользователя/клиента.