問題タブ [paraffin]

CIサーバーでMSIの構築を自動化できるようにする必要があるため、WiXを使い始めたばかりです。プロジェクトのすべての依存関係を自動的に含める方法はありますか?

VS 統合セットアップから WiX に切り替えることにしました。

ただし、現在行っているのは、プロジェクトの出力ファイルをセットアップ プロジェクトの入力として使用することです。これにより、アプリケーション ファイルを (画像、サンプル、その他のリソース用に) ディレクトリに簡単に追加できます。これらのファイルは、ビルド時に自動的にセットアップに追加されます。

WiX には同様の機能が見つかりませんでした。WiX では、ディレクトリとファイルごとに 1 つのディレクトリ エントリと 1 つのファイル エントリが必要なようです。これには、ファイルが追加されるたびに WiX ソースを変更する必要があり、非常に多くのファイルがあるため、私の目には法外なことです。

WiX でそれを行う統合された方法はありますか、または candle を呼び出す前に WiX ソースを作成する独自のタスクを作成する必要がありますか?

ディレクトリ構造に基づいてファイルを自動的に含める方法はありますか？

[ファイルID]タブですべてのファイル名を追加したくありません。

私のビルドプロセスは、必要なディレクトリ構造を作成します。

これらのディレクトリとそのサブディレクトリを追加するにはどうすればよいですか？

私は WIX を初めて使用し、Windows の Program Files ディレクトリ内からコンポーネントを作成しようとしています。コマンド ラインでC:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssembliesに移動し、コマンドを実行し
paraffin -dir ./ -custom GlobalSoftware globalsoftware.wxs -gます。
ここで System.UnauthorizedAccessException が発生します: パス 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies' へのアクセスが拒否されました。管理者としてログインしているときに同じ例外が発生します。

どうすればこの問題を回避できますか?

ありがとう、
ヴェンカット・ラオ

サポート ファイルのロードを含む WiX Fragment を取り込む WiX プロジェクトがあります。

Paraffin を使用して、フラグメントの wsx ファイルを作成しています。現時点では、サポート ファイル フォルダーを変更するたびに、1 行のバッチ ファイルを手動で実行して、適切な引数を使用してパラフィンで実行しています。

代わりに、パラフィンをビルド プロセスの一部として実行したいと考えています。.wixproj ファイル内に何かを追加する必要があると思いますが、実際には何がわかりません。

どうすればいいですか？

インストーラーにいくつかのプログラムプロジェクトからのすべての出力を含める必要があります...私の質問はこの投稿の質問に似ています：ディレクトリ全体またはプロジェクト出力をWiXパッケージに追加する方法

しかし、私はこのリンクで与えられた答えを本当に理解していないのではないかと思います。私が行ったすべての読書から、私はこれを行うためにパラフィンを使用する必要があると思います。しかし、パラフィンを使用するための「最初から始める、ハウツー」リソースはありますか？

私はこのページを読みました：http：//www.wintellect.com/CS/blogs/jrobbins/archive/2008/12/22/paraffin-3-0-now-with-full-wix-3-0-support。 aspx と投稿の1つは、batファイルからパラフィンを呼び出すことに言及しています。これは、インストーラーで「パラフィンを使用する」方法ですか？違いがある場合は、Visual Studioを使用してこのプロジェクトに取り組んでいますが、VisualStudio内からコマンドラインを使用する方法もわかりません。非常に新しい初心者のためのリソースを持っている人はいますか？ありがとう。

含まれているファイルのリストを維持するためにParaffinを使用したい Wix プロジェクトがいくつかあるソリューションがあります。

私の理解では、通常、Paraffin をさまざまな bin フォルダーに向けて、すべてのファイルを収集します。

TFS がソリューションをビルドするとき、OutDir msbuild プロパティをオーバーライドします。これにより、すべてのビルド出力が、各プロジェクトの bin フォルダーではなく、共通の Binaries ディレクトリに送られます。

では、このシナリオで人々はどのようにパラフィンを使用するのでしょうか?

短いバージョン：ビルドサーバーで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がビルド間で安定していることをどのように確認できますか？上で概説したアプローチはどちらも私には満足のいくものではないように思えますが、今私が考えることができるのはそれだけです。