私はInstallshield2009とC＃をいじって、インストール前にシリアルキー（.NETで記述されたアルゴリズム）を検証するセットアッププロジェクトを作成してきました。それは素晴らしい働きをします。
しかし、私は製品のいくつかのバージョンを持っています。現時点では、バージョンごとに個別のセットアッププロジェクトを使用しています。ただし、ファイルの多くは同じですが、ファイルが含まれるかどうかのわずかな違いがあります。検出された有効なシリアルキーに応じて特定のファイルをインストールする単一の展開プロジェクトがあれば、それが気に入っています。
基本的に、Installshieldでこの種のことが可能かどうか疑問に思っています。
前もって感謝します
Windowsインストーラーは、少なくとも、ある種のライセンステクノロジで不適切にインストールされたファイルの使用を防ぐために時間をかけない限り、説明するシナリオにはあまり適していません。シリアル検証dllに、さまざまな機能やコンポーネントが条件付けするプロパティを設定することもできますが、変換によってこれを簡単に回避できます。ライセンス検証の実装に時間をかけた（または取ることができる）場合を除いて、最善の策は、個別のビルド（許可されたファイルの異なるセットごとに1つ）を維持することです。ただし、これらを1つのプロジェクトにマージできる場合があります。
ビルド間で何が異なるかによって、個別のSKUを取得する2つの補完的なアプローチがあると思います。1つ目はリリースごとに最も簡単に指定でき、コマンドラインなどからビルドするリリースを選択できます。2つ目はリリースに関係なく、手動で更新するか、コマンドラインビルドでオーバーライドできます。
リリースフラグ
アイテムのグループを追加の機能に分割し（機能選択ダイアログが乱雑にならないように非表示になっている可能性があります）、リリースごとにリリースフラグを使用して、ビルド時にこれらのファイルを含めたり除外したりできます。これは、コンテンツファイルを変更する場合におそらく最も効果的ですが、別々のSKU間で同じカスタムアクションDLLを引き続き使用します。
パス変数
カスタムアクションDLLへのパスは、ファイルのソースの場所を上書きするために使用できるパス変数で指定できます。対応するエントリ（おそらくファイルテーブルまたはバイナリテーブルのいずれか）が山かっこ内の独自の変数を使用していることを確認してください。そうすれば、ビルド時に個別にスワップアウトすることもできます。これは、カスタムアクションDLLを変更する必要がある場合に意味があり、リリースフラグと一緒に使用できます。
実行時に機能を追加および削除できます。これは、（a）インストーラーのプロパティまたは（b）インストールシールドスクリプトを使用して実行できます。
まず、すべてのバージョンのすべての機能をプロジェクトに追加します。インストールするように選択されていないことを確認します。次に、実行中に方法aまたはbのいずれかを使用していずれかを選択します。
インストーラーのプロパティ（a）は、さまざまな方法で設定できます。コマンドラインは、インストーラー、OSバージョン、存在する特定のregキー、またはDLLのカスタムロジックを介して切り替わります。また、インストーラーのプロパティが特定の値であることに基づいて、機能を含めたり除外したりできます。
（b）に関しては、スクリプトは「機能ツリー」にアクセスでき、FeatureSelectItem（）などを使用してカスタムロジックに基づいてそれらを選択および選択解除できます。