Installshield 2009 Несколько последовательных ключей

Question

Я играл с Installshield 2009 и C#, чтобы создать проект установки, который проверяет серийный ключ (алгоритм, написанный на.NET) перед установкой. Работает отлично.

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

По сути, мне интересно, возможно ли подобное с Installshield.

заранее спасибо

Answer 1

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

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

1. Флаги выпуска

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

2. Переменные пути

   Путь к вашей библиотеке пользовательских действий можно указать с помощью переменной пути, которую затем можно использовать для переопределения исходного местоположения файла. Убедитесь, что соответствующая запись (вероятно, в таблице "Файл" или "Двоичная таблица") использует свою собственную переменную в угловых скобках, а затем вы можете поменять ее отдельно во время сборки. Это имеет смысл, если вам нужно изменить свою DLL пользовательского действия, и может использоваться вместе с флагами выпуска.

Answer 2

Вы можете добавлять и удалять функции во время выполнения. Это можно сделать с помощью (а) свойств установщика или (б) в сценариях установки щита.

Сначала вы добавите все функции для всех версий проекта. Вы должны убедиться, что они не выбраны для установки. Тогда вы будете использовать любой метод a или b, чтобы выбрать один во время работы.

Свойства установщика (а) могут быть установлены различными способами. Командная строка переключается на установщик, версии ОС, определенные ключи reg или с помощью пользовательской логики в DLL. А функции могут быть включены / исключены на основе определенного значения свойства установщика.

Что касается (b), сценарий имеет доступ к "дереву объектов" и может выбирать и отменять их выборку на основе пользовательской логики с помощью FeatureSelectItem() и т. Д.