短いバージョン：ビルドサーバーでParaffinを使用して、コンポーネントGUIDが安定していることを確認するにはどうすればよいですか？
私は現在、WiX経由で展開する必要のあるプロジェクトに取り組んでいます。これはWebプロジェクトであるため、多くのファイルが含まれています（まだ初期段階で、すでに200近くのファイルがあります）。また、開発中、ファイルは絶えず追加および削除されるため、WiXコンポーネントリストを手動で維持することは単にオプションではありません。
コンポーネントルールについてたくさん読んだので、それらを破る人々は地獄に行くので、私は収穫機としてパラフィンを使うことにしました。このツールは、既存のコンポーネントリストを更新できるため、既存のコンポーネントの新しいGUIDを再作成することはできません。
ただし、新しいコンポーネントが作成されると、ツールは新しいGUIDを割り当てます。コンポーネントファイルが同一であっても、初期GUIDは、マシンごとに、または時間によってのみ異なります。
したがって、明らかに、最初のGUIDを修正するための中央権限が必要です。私のアイデアは、空のコンポーネントリストをコミットすることでした。このリストは、ビルド時にParaffinを呼び出すビルドサーバーによって埋められます。したがって、ビルドサーバーによって作成されたMSIのみを配布する場合、コンポーネントのルールが守られていることを確認できます。
ただし、このアプローチの問題は、ビルドサーバーがクラッシュしたり、ローカルリポジトリが空になったりした場合に、GUIDを追跡する手段がないことです。ビルドサーバーに生成されたコンポーネントリストをリポジトリにコミットさせることを考えていましたが、それはクリーンなアイデアではないようです。
私が考えたもう1つの解決策は、コミットする前にすべての開発者にビルドさせる（したがって、Paraffinと呼ぶ）ことでした。したがって、各開発者は、新しく追加されたファイルの初期GUIDを作成し、それらをコンポーネントリストにコミットします。
このアプローチの明らかな問題：人々（例えば開発者A）はコミットする前にビルドするのを忘れます。したがって、これらの場合、ビルドサーバーは新しいファイルの初期GUIDを作成しますが、それらもローカルにのみ保存されます。数回のコミットの後、開発者Bがやって来てソリューションをビルドし、開発者Aが作成したファイルの新しいGUIDを作成します。開発者Aは、このGUIDを含むコンポーネントリストをコミットし、ビルドサーバーがそれをチェックアウトします。これで、ビルドサーバーはパッケージのGUID（開発者Aによって作成された）を取得しました。ファイルはその間に変更されていませんが、以前は別の（自己作成された）GUIDを使用していました。
では、開発者がコミットする前にソリューションをビルドすることに依存することなく、GUIDがビルド間で安定していることをどのように確認できますか？上で概説したアプローチはどちらも私には満足のいくものではないように思えますが、今私が考えることができるのはそれだけです。