Самостоятельная установка приложения или отдельный установщик?

Question

Для установки приложения на новый компьютер в настоящее время существует два основных подхода:

1. Отдельный установщик: создайте отдельный установочный пакет который создает все каталоги, файлы, записи реестра, необходимые для вашего приложение (т.е. MSI, InstallSheild и т. д.), а затем, наконец, копирует ваше приложение на целевой компьютер.
2. Самостоятельная установка: включите все необходимые шаги установки в компоненте это часть вашего заявления. Затем используйте этот компонент для проверки и создания необходимых настроек при каждом запуске исполняемого файла основного приложения. т.е. просто запустите приложение для установки.

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

Кроме того, во время программных проектов, над которыми я работал, отдельный подход к установщику часто диктовал распространение знаний, специфичных для приложения, как в пакете установщика, так и в реальном приложении. Затем, когда были внесены изменения в код / ​​функциональность, нужно было обновить и программу установки, и приложение. Это всегда казалось слишком хрупким и склонным к человеческим ошибкам.

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

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

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

Так какой подход к людям рекомендуется и почему?

(в настоящее время меня больше всего интересует установка приложений для настольных клиентов).

Answer 1

Есть плюсы и минусы обоих подходов:

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

• На самом деле могут быть требования к процедуре установки с использованием сценариев в корпоративных средах.

• Отсутствие установщика открывает путь к переносимым приложениям. Если у программы есть все в каталоге, то это можно просто скопировать на USB-накопитель и запустить в любой системе. Это, конечно, может не иметь смысла для вашего конкретного типа приложения, но вам решать.

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

Редактировать: Вы пишете в своем комментарии:

Даже переносные приложения требуют определенных настроек / настроек. Разве лучше, чтобы основное приложение проверяло, что настройки действительны / существуют при каждом запуске, и запрашивает пользователя только при необходимости.

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

• Настройки конфигурации для каждого пользователя будут отсутствовать, если приложение впервые запущено текущим пользователем. Может быть полезно показать сообщение о том, что оно отсутствует, и о том, как его создать. Например, в FlameRobin (программа администрирования базы данных для Firebird) у нас есть сообщение, которое отображается, когда при запуске программы не найдено зарегистрированных серверов и баз данных, и как их зарегистрировать.

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

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

Answer 2

Переход с отдельного установщика является "лучшим" способом с моей точки зрения. Самостоятельная установка приложения не только добавляет дополнительную рабочую нагрузку к самому приложению, но также «обходит» любую систему установки базовой операционной системы (например, MSI на Windows).

И если приложение со временем испортило свои настройки, оно сломалось и должно быть исправлено. Как поврежденные настройки должны обрабатываться самоинсталлятором? Просто переписать его с настройками по умолчанию? Это тоже раздражает пользователей, поэтому наличие у них отдельного установщика и выбор опции «исправление» делает это как минимум более прозрачным.

Answer 3

Я бы порекомендовал отдельный установщик, который может делать следующее:

• Установить новую установку
• Восстановление существующей установки
• Удалить существующую установку

Причина, по которой я рекомендую эти параметры, заключается в том, что именно этого я и ожидал от установщиков в среде Windows.

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

• Могут быть конфликты между зависимостями, используемыми установщиком и приложением.
• Я хочу быть уверен, что моя команда не использовала случайно классы в зависимостях от среды установщика при разработке приложения.

Answer 4

Спасибо за ваш отзыв. Я начинаю думать, что что-то вроде этого было бы хорошим компромиссным подходом:

• Выберите подход самоинсталлятора, создав компонент установщика (библиотеку классов), на который ссылается основное приложение.
• Этот компонент является основной частью приложения и отвечает за то, чтобы все конфигурации / настройки существовали и были действительными.
• Основное приложение. Исполняемый файл при каждом запуске просит этот компонент проверять наличие / действительность настроек и запрашивать пользователя только при необходимости. Это можно легко сделать удобным для пользователя способом, сгруппировав все проблемы с настройками и представив их в одном графическом интерфейсе (избегая последовательности раздражающих диалогов).
• Для интеграции с ОС компонент установщика (в случае Windows) обеспечивает добавление записи в список «Установка и удаление программ» для приложения, а также любых других соглашений, необходимых для ОС.
• В приложении стандартный экран параметров / настроек также предоставляется компонентом установщика. Это позволяет избежать дублирования кода управления настройками.

Я задал этот вопрос, потому что я встретил многих нетехнических пользователей, которые спрашивают, почему они не могут просто скопировать приложение с одного компьютера на другой, они могут сделать это с помощью своих данных (например, фотографий, документов и т. Д.). Это чрезвычайно актуальный вопрос, особенно для настольных приложений, ориентированных на GUI.

Отдельные установщики, безусловно, "так, как это было сделано" в Windows в течение многих лет. Для драйверов / компонентов системы, очевидно, они часто являются необходимостью. Но для настольных приложений в стиле GUI я не верю, что они являются лучшими с точки зрения простоты и надежности для пользователя / клиента.