WiX にはツールセット中の各種のツールから生成される 多くのファイルの種類があります。 最も高いレベルでは、WiX のためのすべての入力ファイルと中間ファイルが XML ファイルです。 出力は標準の Windows インストーラーデータベースファイルの形式でです。
ソースファイル（ .wxs と .wxi ）は、オブジェクトファイル（ .wixobj ）を作り出してコンパイルされます。 これらのオブジェクトファイルはそれからリンカによって消費されて、Windows インストーラーデータベースファイル（ .msi か .msm ）を作り出します。 これは、実行可能ファイルを作り出す為にソースコードをオブジェクトファイルにコンパイルしてリンクしている C++ モデルと似ています。
以下のリストは、WiX 中でサポートされるファイルの種類を説明しています：
| 拡張子 | タイプ | 説明 |
|
.wxi |
WiX インクルード ファイル |
.wxi ファイルは、C++ の為の .h ファイルに似ています。このファイルのルートエレメントは <Include> です。 このファイルが別のソースまたはインクルードファイルに含められている時には、ルートエレメントの下のすべてのものがインラインで挿入されます。 |
|
.wxl |
WiX ローカライズ ファイル |
.wxlファイルには、プロダクトを指定されたカルチャーにローカライズするために使用される文字列のセットが入っています。 このファイルのルートエレメントは <WixLocalization> です。 カルチャーは、<WixLocalization> エレメントで Culture 属性をセットする事によって指定されます。 |
|
.wxs |
WiX ソース ファイル |
.wxs ファイルは C++ の為の .cpp ファイルに似ています。このファイルのルートエレメントは <Wix> です。 |
|
.wixobj |
WiX オブジェクト ファイル |
.wixobj ファイルはコンパイラにより、コンパイルされた個々のソースファイルごとに作成されます。 .wixobj ファイルは、順にシンボルと他のシンボルへの参照を含んでいる1つ以上のセクションを含んでいます。 |
|
.wixout |
WiX XML 出力ファイル |
.wixout ファイルはリンカにより作成され、一連のオブジェクトファイルのリンクの結果に相当します。 .wixout は最終的な出力結果の XML 表現です。 |
|
.wixlib |
WiX ライブラリ ファイル |
.wixlib ファイルは、セットアップパッケージをリンクする時にそれをインクルードする事によって、WiX ベースの異なるパッケージをまたいで容易に共有できる セットアップ機能のライブラリです。 |
|
.wixpdb |
WiX デバッグ ファイル |
.wixpdb ファイルはリンカにより、個々の最終的な出力ごとに作成されます。それはデバッグ情報を含んでいます。 |
|
.wixmsp |
WiX XML パッチ ファイル |
.wixmsp ファイルは、パッチビルド中にオブジェクトファイルをリンクすることによって生成される XML 出力です。 |
|
.wixmst |
WiX トランスフォーム ファイル |
.wixmst ファイルは、1対の最終的な出力または XML 出力の相違点の XML 表現です。 |
|
.msi |
Windows インストーラー インストールパッケージ |
インストールパッケージファイル（ .msi ）は、Windows インストーラーのための インストールの基本ユニットです。 .msi ファイルに於けるより多くの情報に関しては、Windows Installer documentation を見て下さい。 （Installer Database） |
|
.msm |
Windows インストーラー マージモジュール |
マージモジュールファイル（ .msm ）は、異なる .msi パッケージをまたいでセットアップロジックを共有するのに用いられます。 マージモジュールは1つの開発チームにより作成され得て、そして別の開発チームの .msi パッケージにマージされます。 .msm ファイルに於けるより多くの情報に関しては、Windows Installer documentation を見て下さい。 （Merge Modules） |
|
.mst |
Windows インストーラー トランスフォーム |
トランスフォームファイル（ .mst ）は、.msi ファイルに変更を適用するのに用いられます。 .mst ファイルに於けるより多くの情報に関しては、Windows Installer documentation を見て下さい。 （Merges and Transforms） |
|
.pcp |
Windows インストーラー パッチ作成プロセス |
パッチ作成プロパティファイル（ .pcp ）は、Windows インストーラー SDK 中で提供されるパッチ作成ツールへのインプットとして使われます。 .pcp ファイルに於けるより多くの情報に関しては、Windows Installer documentation を見て下さい。 （Patchwiz.dll） |
.wxs ファイルは、Windows インストーラー XML システムのすべてのソースファイルによって使用されます。 これらの .wxs ファイルは C++ の為の .cpp ファイルまたは C# の為の .cs ファイルと似ています。 .wxs ファイルはプリプロセスされて、それから 拡張子 .wixobj を使う WiX オブジェクトファイルにコンパイルされます。 ソースファイルのうちのすべてがオブジェクトファイルにコンパイルされた時、オブジェクトファイルを一緒にまとめ Windows インストーラーデータベースを作成するのに リンカが使用されます。 コンパイラとリンカに於けるより詳しくは、このトピック中で後程提供されます。
ルート <Wix> エレメントは子として以下の要素のうちの最大1つを含む事ができます： <Product>, <Module>, <Patch> 。 けれど、ルート <Wix> エレメントの子として無限の数の <Fragment> エレメントがあるかもしれません。 ソースファイルがオブジェクトファイルにコンパイルされた時には、これらのエレメントの個々のインスタンスは、オブジェクトファイルの新しいセクションを作成します。 従って、これらの3つのエレメントはよくセクションエレメントとして参照されます。
<Product> や <Module> や <Patch> セクションエレメントは、エントリーセクションと呼ばれる特別なセクションにコンパイルされるので、それらはソースファイルあたりただ一つだけある事ができる事に、注意する事が重要です。 エントリーセクションはリンクプロセスにおいて出発点として使われます。 セクション、エントリーセクション、および全体のリンクプロセスは、このドキュメントにおいてもっと詳しく後で説明されます。
セクションエレメントの子は Windows インストーラーデータベースの内容を定義します。 プロパティテーブル中のエントリーにマップする <Property> エレメントと、ディレクトリテーブルを組み立てる <Directory> エレメントの階層が、分かるでしょう。 ほとんどのエレメントは、Windows インストーラーデータベース中の 結果として生じる行のためのプライマリキーとして作動する “Id” 属性を含んでいます。 ほとんどのケースにおいて、ソースファイルがオブジェクトファイルにコンパイルされる時には、“Id” 属性はシンボルも定義します。
オブジェクトファイル中のすべてのシンボルは “Id” 属性から、エレメント名たすユニークな識別子により構成されています。 シンボルはどのようなソースファイルからでも他のセクションにより参照されうるので、シンボルは重要です。 例えば、<Directory> 構造が あるソースファイルの <Fragment> 中で定義され得て、<Component> が違うソースファイルの <Fragment> の下で定義され得ます。 <DirectoryRef> エレメントを <Component> の親にすることによって、最初のソースファイルの <Directory> により定義されたシンボルを参照する 明示的な参照が作成されます。 リンカはその時、単一の Windows インストーラーデータベース中にシンボルと参照を一緒に縫い合わせることについて責任を持ちます。 場合によっては、ソースファイルを処理する間、暗黙の参照がコンパイラにより生成されます。 これらの暗黙の参照は明示的な参照と全く同じに振る舞います。
上で説明した簡単な参照だけでなく、WiX は特有な複雑な参照をサポートします。 複雑な参照は、シンボルと参照を連結するために、リンカが特別な情報を生成しなければならないケースに用いられます。 複雑な参照の完全な例は、Windows インストーラーの Feature/Component 関係にあります。 <Component> が <Feature> によって <ComponentRef> エレメントを通して明示的に参照される時には、リンカは、 <Feature> のシンボルと <Component> のシンボルを取り、エントリーを FeatureComponents テーブルに追加しなければなりません。
この Feature/Component 関係はいっそう複雑です。なぜなら、<Component> 中のある要素、例えば <Shortcut> は、Component と結び付いたプライマリーフィーチャーに戻る参照を持っているからです。 <Component> の子エレメントからのこれらの参照は、逆参照 または時々フィーチャーバックリンクと呼ばれます。 複雑な参照と逆参照を処理することはおそらく、リンカがやらなければならない最も難しい仕事です。
.wixobj ファイルはコンパイラによって、コンパイルされたソースファイルごとに作成されます。 .wixobj ファイルは、WiX プロジェクトにおいて定義された objects.xsd スキーマに従った XML 文書です。 上で述べたように、.wixobj ファイルは、シンボルと他のシンボルへの参照を交互に含んでいる1つ以上のセクションを含んでいます。
シンボルと参照が間違いなく .wixobj ファイルのデータの中で最も重要な断片であるのに対して、それらはめったに情報の大部分ではありません。 代わりに、ほとんどの .wixobj ファイルは Windows インストーラーデータベースに置かれる生データを提供する <table> 、<row> 、<field> エレメントにより構成されています。 多くのケースにおいて、リンカはシンボルと参照を処理するだけではなく、.wixobj ファイルから生データを使いアップデートもします。 オブジェクトファイルスキーマ objects.xsd がキャメルケーシングを使い、そこでソースファイルスキーマ wix.xsd がパスカルケーシングを使う事に気づく事が興味深い。 これは、オブジェクトファイルがユーザーにより編集される事を意図しない事を示す 意識的な選択でした。 実のところ、WiX ツールだけにより処理されるデータを定義するすべてのスキーマが、キャメルケーシングを使います。