Установщик с онлайн-регистрацией для приложения Windows

Ответ 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.

Ответ 2

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

• LogicNP
• DESAWARE

Поскольку это очень широкий вопрос, трудно объяснить детали реализации низкого уровня. Я могу дать вам направление.

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

• Показывать пользовательскую форму во время установки
• Как добавить дополнительное настраиваемое окно в поток пользовательских интерфейсов VS-проектов

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

Ответ 3

Возможно, вы можете попробовать Inno Setup, которая является бесплатной (даже с открытым исходным кодом) системой установки.

Это script, который позволяет вам настроить ваш установщик и выполнить в нем все!

Создание пользовательской страницы с вводом серийного номера очень просто, см. этот пример: CustomPage для серийного номера в Inno Setup

а также для интеграции с Visual Studio.