InstallAwareのドキュメントは驚くほど貧弱で、しかも英文しかありません。
しかしそれに反してソフトは評価できます。
InstallAwareでは[Windows Installer]の仕様に沿った3タイプのセットアッププログラムを作成します。
すなわち単一圧縮ファイル、CDあるいはDVDに焼き付ける形およびWEBからインストールする形です。
WEBインストールでは、
インストールが始まった時は必要最小限のプログラムだけダウンロードし、
インストールの途中で必要になったソフトを、
設定URLからダイナミックにダウンロード・インストールするようになっています。
また当該プログラムが動作するために必要なRuntimes（.NETやSQL Server等）がすでにインストールされているかどうかを確認し、
なければこれらをインストールします。
標準では用意されていないRuntimes（例えばAccessRunTime）の検査およびインストールも、
比較的容易にコーディングできます。
ただしRuntimesに関して一つの欠点があります。
WEBインストールではRuntimesをWEBに置くので問題ないのですが、
その他のインストールでは、
アプリケーションプログラムが必要とするすべてのプログラムをセットアッププログラムに入れておかなければいけません。
SQL Server等Runtimesは一般に大きなプログラムですし、
ターゲットコンピュータにはすでにインストールしてあって、
改めてインストールする必要がないかもしれません。
CDやDVDの場合は良いのですが、
単一ファイルにしてダウンロードする場合は、
ダウンロードそのものが大変ですし、その上無駄な作業になる可能性があります。
単一ファイル・セットアップをインターネットからダウンロードする形で使わないで、
WEBインストールかメディアインストールかにすればいいのでしょうが、
下に書きますようにWEBインストールでは手間暇かかるので、
すくなくともデバッグの途中では単一ファイルをWEB上に置きたくなります。
WEBインストールに問題があります。
上で書きましたが、WEBインストールでは最小限のセットアッププログラムと、
Runtimes等のいくつかの７zipファイルを作りますので、
これらの７zipファイルを指定のURLにアップロードしなければいけません。
これらのファイル名はInstallAwareの中では、大文字小文字が混ざっています（ケース・センシティブ）。
例えば、[Microsoft .NET Framework Client 4.7zip]のようです。
ところが、InstallAwareはWindowsの開発環境にセットアッププログラムの一部として
[microsoft .net framework client 4.7zip]のようにすべて小文字のファイルを出力します。
InstallAwareのユーザは、
小文字のファイル名を[Microsoft .NET Framework Client 4.7zip]のように変更して、
所定のURLにアップする必要があります。
セットアッププログラムのデバッグでビルドする度に、
何度も何度もファイル名の変更とアップロードが必要になります。
この表現は正確ではありません。
ファイルはいくつかのRuntimesと
ユーザが設定する[Program Files]や[Data Files]等のFeaturesに対応して作成されますが、
Runtimesは毎度同じですから何度も作成しなくてよいのです。
その代りデバッグ中のFeaturesはその都度更新しアップすることにないｒます。
Featuresはセットアッププログラム特融の概念です。専門的で申し訳ありません。
InstallAwareのForumでもこのことにクレームがきていました（2008年）。
「アップするサーバーがLinuxの場合ファイル名はケース・センシティブだから、
これに対応するように改良してほしい」というものです。
とことがInstallAwareの開発者は、
「Windowsではファイル名は大文字でも小文字でも同じ扱いだからこれでいいのだ」
「だいたいInstallAwareはWindows用のツールなのだ」と見当違いの主張をします。
明らかにユーザの主張が正しいのですが、
大体InstallAwareがそのことを認識していないことに驚く次第です。
最近のInstallAwareの別のスレッドの回答では「改良検討中」になっていました。
私は仕方ないのでPerlで、
ファイル名を変更して指定のURLにアップするプログラムを書き、
InstallAwareでビルドする度にこのプログラムを実行することしました。
Perlはこういう仕事に適しています。
それにしてもこれはInstallAwareの中で処理すべきです。
インストールでよく使われている、
ユーザ名とシリアル番号の入力を促すセットアッププログラムの例が標準で用意されています。
インストールしようとしているアプリケーションプログラムの依存Dllの検出は、
InstallAwareの中で当該アプリケーションを動作されることで収集できますが、
使ったすべてのDllをユーザのプログラムフォルダにコピーする仕組みになっていますので
「これはいらないのではないの」というもの（例えばマウスのドライバー）も入ってきます。
マイクロソフトのセットアッププログラムでは、
必要最小限の依存プログラムを収集します。
InstallAwareでそれだけを組み込んでセットアッププログラムを作成しても正常動作しますので、
「それでもいいのでは?」と思っています。
InstallAwareそのものはすべて英文ですが、
作成したセットアッププログラムでのインストール時の表示は、
比較的容易にローカライズ（日本語化）できます。
またインストール用画面（ダイアログ）も自分で作成できるようですが、使ったことがありません。
InstallAware2012にはTrialWareというツールがあります。
デモ用でインストール後に期限切れにする仕組みを作成します。
「ある回数使ったら」とか「何日たったら」とか色々な設定ができます。
eCommerceと組み合わせて、try-and-buyの仕組みにできそうです。
私はとりあえずtry-and-dieの仕組みだけ使って、
「期限がきたら終わり」という形にしたいと思います。
私はこれまで、デモ版ではアプリケーションプログラム本体で機能を制限していましたが、
TrialWareではプログラム自体は変えないで、
セットアッププログラムで期限切れを設定するだけなので「とても使いやすいかな」と思っています。
ただし悪いことに「あと何日で期限切れです」
という案内は日本語がでません。
TrialWareにバグがあります。
アプリケーション・プログラムのExeファイルを、
スタンドアロンで期限チェックプログラムのラップをして、
このラップされたEXEを、
InstallAware2012 IDEでセットアッププログラムに組み込めば問題ないのですが、
IDEの中でいっきにこの処理をしようとするとエラーになります。
メーカーに調査依頼しています。
回答待ちです。
秀逸なのはPatchプログラムです。
アプリケーションプログラムを改変したとき、
ユーザが使用しているプログラムにPatchをあてなければいけません。
InstallAware2012では古いセットアッププログラムから容易にPatchプログラムを作成できます。
変更のあった部分を自動で認識し、
アプリケーションの環境でその部分（Featureを構成するComponent単位で）を入れ替えるようです。
PatchとかUpdateとかは、Windows Installerの仕様のようですが、
プログラムの更新が容易にできる仕組みはすばらいいです。