Ответ 1
One-Shot Setups: "
A setup is run once, an application can be started again - in order to resolve and debug problems interactively - with meaningful error messages show to the user."Hence:
avoid license validation in the setup.
Краткая версия о лицензировании.
Лицензионный ключ: предпочтение иметь дело с лицензионными ключами в вашем приложении кажется логичным по нескольким причинам:
the one-shot nature of setupsдаетpoor reliability(нет интерактивной отладки - плохая способность решать проблемы). Конечный результатlots of support callsдля чего-то очень тривиального.Кроме того,
risk of piracy and hackingявляется серьезной проблемой, когда выставление DLL проверки лицензии в настройке. И наконецcommunication over the Internetсложно с современными настройками (proxies,firewalls,etc...) - что является современным способ проверки лицензии ключи (в будущем установки могут иметь полный доступ к Интернету, но будьте осторожны, предполагая, что слишком много, поскольку у корпоративных пользователей может быть множество ограничений, а неправильное развертывание может повредить продажам и принятию программного обеспечения для корпоративного использования).Наконец, ваше приложение должно обычно поддерживать
trial version, и тогда вам нуженlicense dialog in your applicationв любом случае. Зачем усложнять настройку?Центры сертификации: настраиваемые действия являются сложными и в целом подвержены сбоям - из-за сложных
sequencing-,conditioning-иimpersonation issuesи в целомpoor debugability. Больше информации: Почему рекомендуется ограничивать использование пользовательских действий в моих настройках WiX/MSI?
Общая сложность развертывания. Краткое описание общей сложности развертывания: Установщик Windows и создание WiX(раздел
"The Complexity of Deployment").
Я бы удалил все лицензионные функции из установки и добавил бы их в приложение. Ваша установка все еще может записать лицензию на диск или в реестр, передав ее msiexec.exe как общедоступное свойство - Свойства UPPERCASE (или вы можете немного "спрятать" вещи, используя преобразование для применения свойства serial - это имеет тот же эффект, что и установка свойства в командной строке). Вы также можете установить свойство LICENSE из диалогового окна в настройке, когда оно запускается в интерактивном режиме, но мой любимый подход - разрешить добавление лицензионного ключа без проверки в реестр в режиме без вывода сообщений и вместо этого ввести лицензионный ключ непосредственно в приложении, а не в настройке, для интерактивных развертываний (приведенное выше описание предназначено для скрытого развертывания):
msiexec.exe /I "C:\Install.msi" /QN /L*V "C:\msilog.log" LICENSE="123-456-789"
- Это позволит легко добавить лицензию на каждый компьютер в сценарии корпоративного развертывания. Значение лицензии просто записывается на диск или в реестр без проверки. Приложение проверит это (более безопасно, чем dll проверки в настройке).
- Нет необходимости связываться с сложными диалоговыми окнами настройки, но вам потребуется лицензионный диалог в приложении, как описано ниже.
- Как разработчику установки, вы должны предложить внедрить эту функцию в приложении вместо установки, чтобы она не выглядела как "прохождение блага". Это все из-за общей надежности программного обеспечения и защиты от дурака - и несколько причин перечислены ниже.
- Почти все крупные корпорации развертывают файлы MSI в режиме без вывода сообщений, поэтому графический интерфейс настройки в любом случае будет игнорироваться в большинстве случаев. Затем вы просто добавляете риск и тратите ресурсы, если имеете дело с лицензиями в настройке.
- Один недостаток: приложение, запущенное как пользователь без прав администратора после установки, не может записать в HKLM общий доступ к последовательному порту для всех пользователей на компьютере (установка, работающая с повышенными правами, может). Он должен либо выполнить запись в HKCU, либо программа установки должна подготовить доступ для записи к определенному местоположению HKLM в реестре, чтобы приложение могло выполнить запись. Я предпочитаю писать в HKCU для каждого пользователя, так как тогда лицензия становится менее доступной для копирования другими пользователями и хранится в виде пользовательских данных (допускает роуминг, хотя большинство ИТ-специалистов это ненавидит). Однако лицензионный ключ HKLM, написанный приложением или программой установки во время установки (как описано выше с набором открытых свойств), позволяет всем пользователям совместно использовать лицензию при запуске приложения.
Существует несколько более конкретных причин, чтобы запретить обработку и проверку лицензии:
- Значительное количество запросов в службу поддержки всегда возникает в результате того, что люди испытывают проблемы с регистрацией своих лицензионных ключей в настройке. Установка запускается один раз, и при возникновении проблем приложение можно запустить снова. Это важнее, чем вы думаете, для неопытных пользователей. У вас также есть улучшенные функции для обработки исключений и состояний ошибок и любых непредвиденных проблем, которые могут возникнуть в приложении.
- Последовательная проверка в настройке предоставляет dll/метод проверки, который легко взломать пиратами. Вы не предотвратите пиратство, удалив его из настроек, но, по крайней мере, усложните его. Это более безопасно в приложении, если вы немного скрываете вещи (статическое связывание, шифрование, обфускация, перевод процесса проверки в оперативный режим и/или все, что делается профессионалами в области безопасности, с которыми я не знаком).
- Разрешить пробную версию приложения: если для настройки требуется поддержка пробной версии приложения, вы должны разрешить пользователю вводить лицензионный ключ, если он в конечном итоге приобретает продукт - предпочтительно без необходимости повторной установки. -запустите установку или удалите/переустановите просто для добавления лицензионного ключа. Другими словами, вам, скорее всего, придется столкнуться с лицензированием в вашем приложении, так или иначе, зачем усложнять настройку? Больше риска, больше QA, больше потенциальных запросов в службу поддержки и многократных необходимых исправлений как в настройке, так и в приложении. Высокая общая стоимость?
- Если ваше приложение работает с различными версиями, что если пользователь купит обновленную лицензию? Они должны просто иметь возможность ввести его в диалоговое окно лицензии и, если возможно, разблокировать функции, а не удалять и переустанавливать все связанные с этим блокировки. Однако для некоторых обновлений это трудно достичь, и вам часто приходится иметь отдельные настройки для разных выпусков.
- Если в сети используется прокси-сервер для доступа в Интернет, у вас будут проблемы с регистрацией лицензии через Интернет во время установки (часто запрашивается маркетингом). У вас есть больше возможностей для проверки и решения этой проблемы в приложении - оно может повторить попытку и дождаться доступа (обычно вы подключаетесь к IE для автоматической настройки прокси-сервера, если это возможно). Для корпоративного развертывания вам также нужна опция автоматической установки, которая не проверяет ключ, а просто записывает его в реестр. Попытка получить доступ к Интернету с помощью автоматической установки MSI, на мой взгляд, является довольно экстремальным анти-паттерном развертывания. Я нахожу это сомнительным в настройке GUI также. Выполните регистрацию в приложении - гораздо менее спорным, и вы можете настроить правила брандмауэра, чтобы разрешить ему доступ к сети Интернет (msiexec.exe, скорее всего, блокируется - и по уважительной причине). Также могут существовать аппаратные брандмауэры и/или программное обеспечение для обеспечения безопасности, которое затрудняет или даже делает невозможным доступ в Интернет без какой-либо неуклюжей конфигурации административного сервера. Мой опыт может привести к гибели вашего программного обеспечения.: "Просто извлеките это из нашей сети и приложений - должны быть лучшие варианты - слишком неуклюжие и подверженные ошибкам".
- ОБНОВЛЕНИЕ: По мере того, как технология развертывания развивается и становится все более "основанной на Интернете", эта "истина" может измениться, и мы можем в конечном итоге сделать все "онлайн" с развертыванием, специально разработанным для запуска, например, через онлайн-хранилища. Придется подождать и посмотреть. На данный момент я считаю, что любые требования к настройке доступа в Интернет ошибочны и нежелательны.
- Установки, которые мешают лицензированию, могут иногда приводить к удалению лицензионных данных во время сценариев обновлений, исправлений и миграции из-за ошибок в настройке. Временами это намного серьезнее, чем вы думаете - пакет может поразить тысячи рабочих станций в крупных компаниях и будет трудоемким для исправления.
- В самой технологии MSI существует довольно плохое "антишаблон", при котором самовосстановление или восстановление, инициируемое вручную, сбрасывает значения в реестре, которые были изменены приложением. Это может стереть лицензионные ключи. Мы видим это все время, и это технологическая ошибка. Это просто не логично в этой области.
- Для этого есть некоторые исправления (или, скорее, обходные пути) (используйте постоянный компонент, пишите лицензию из пользовательского действия, а не из компонента и т.д.), Но я нахожу их довольно неуклюжими, и у вас должен быть большой опыт знать все подводные камни - и даже опытные пользователи испортят это.
- Лицензирование - это огромная корпоративная головная боль - часто компании или корпорации часто требуется, чтобы лицензирование осуществлялось централизованно на сервере, а не на основе текстовых серийных номеров вообще (например, параллельные или плавающие лицензии, полученные при запуске приложения через сеть). Просто упоминание об этом, хотя это как бы выходит за рамки вопроса. В этих случаях при установке обычно указывается IP-адрес, указывающий на сервер лицензий, или просто обычное имя хоста, которое должно быть разрешено с помощью WINS или DNS.