4

3つの部分からなる製品があります。

  • アプリケーションファイル(exeおよびdllファイル)
  • ヘルプファイル
  • SSRSレポート

3つすべてが、WIXを使用して構築された同じインストーラーと一緒にインストールされます。私たちの会社では、各コンポーネントは別々のチームによって、異なる期限で開発されています。MSIを3つの部分に分割して、1つの部分が安定したときに、インストーラー部分も安定し、他の部分が更新されたときに最初から再構築されないようにします。

マージモジュールとCABファイルを見てきましたが、それは間違った方向だと思います。WIXツールセットに私の目的を達成するのに役立つものはありますか?

MSIインストーラーとSeparaeteインストールファイルの作成に関する質問を読みましたが、この質問は少し異なると思います。)

ご協力いただきありがとうございます。

4

2 に答える 2

3

WiXライブラリ(*.wixlib)は、ケース内のコンポーネントを配布するための最良のアプローチのようです。

私はこのプロセスを次のように整理します:

  • 各チームには個別のWiXインストールプロジェクト(セットアップライブラリプロジェクト)が*.wixlibあり、MSI(またはMSM)パッケージの代わりにファイルにコンパイルされます
  • 各プロジェクトは、コンポーネントが開発されるにつれて進化し、出力は他のチームと共有されます
  • 統合ビルドは、すべてのwixlibライブラリとリンク(light.exe)をすべて1つのMSIパッケージにまとめます。

したがって、コンポーネントの最新ビルドを含む最終的なインストールパッケージが常にあります。これが、継続的インテグレーションのすべてです。

私が理解している限り、コンポーネントを個別に配布することはありません。エンドユーザーにとっては、それでも確実なインストールパッケージです。したがって、マージモジュールはオーバーヘッドになる可能性があります。マージツールと比較して、ライブラリをリンクするときにlight.exeが追加の検証を実行するのではないかと思います(確かではありません)。

于 2012-10-24T11:13:37.267 に答える
2

さて、マージモジュールは解決策です。ヘルプファイルとSSRSレポートを含む2つのマージモジュールを作成し、それらをアプリケーションファイルのみを含むメインパッケージに追加することができます。これにより、2つのマージモジュールで何も変更されていない場合にビルド時間が長くなる可能性がありますが、メインパッケージの変更には長いビルド時間がかかります。

もう1つのオプションは、コンポーネントごとに個別のパッケージを作成し、Burnを使用してそれらを1つのパッケージにバンドルすることです。よりクリーンで管理しやすいマージモジュールを使用することをお勧めします。

于 2012-10-24T06:00:44.920 に答える