3

適切な構成などでプロジェクトを再構築するために、インストーラーに事前構築イベントがあります。

Visual Studio で WiX (3.0) プロジェクトのビルド/再ビルドを右クリックすると、すべて正常にビルドされますが、wixproj ファイルで MSBuild を実行しようとすると、ビルド前のイベントでエラーがスローされます。

代わりに、wixproj で Candle と Light を呼び出すことはできますが、ビルド前のイベントは実行されません。

ビルド前のイベントは VS が提供するマクロに依存しており、別のプロジェクトを作成する以外にそれを回避する方法がわかりません。基本的には、ハックを叫ぶプロジェクトのビルド前のイベントを使用するだけです。

もう 1 つの問題は、コマンド ラインから自動更新バージョン番号を WiX に入力する必要があることです。

csproj だけを使用してバージョン番号を処理し、それを更新して、MSBuild と Candle と Light にシェルするだけを計画していましたが、問題は、ハードコーディング以外のコードからソリューション ディレクトリにアクセスする方法がわからないことです。それは

4

2 に答える 2

2

ユーティリティを使用してプロジェクト自体を編集し、オートビルダー (この場合はVisualBuild )でビルドする前にビルド前およびビルド後のすべてのイベントをダンプするのが最も簡単であることがわかりました。

これにより、IDE の厄介なハックに依存せず、ソースがどこから来て、ビルドされたコンポーネントがどこに行くかを完全に制御できる、素晴らしくジューシーなビルド プロセスが得られます。

于 2009-01-27T04:47:27.433 に答える
-1

ここで説明した、私にとってはうまくいく別の方法を使用しています。

  • バージョン番号をバッチ ファイルに保持し、環境変数に書き込むだけです。
  • 最初に「バージョン番号」バッチ ファイルを呼び出すバッチ ファイルを実行してリリース ビルドを作成し(そのため、環境変数にバージョン番号が含まれています%VersionNumber%)、次にMSBuild プロジェクト ファイルを実行します。
  • MSBuild プロジェクト ファイルはソリューションをビルドします。ファイル内の.csproj.exe のバージョン番号は、存在する場合は環境変数から読み取って取得します (次に、MSBuild コミュニティ タスクAssemblyInfoを使用して、バージョン番号が含まれるファイルを事前に作成します)。ビルド イベント)
    これは、Visual Studio からビルドした場合、.exe のバージョンが 0.0 であることを意味しますが、バッチ ファイルからすべてのリリースを作成しているため、問題ありません。
  • WiX セットアップでリリース ビルドを作成するには、上記の「ビルド」バッチ ファイルを呼び出す別のバッチ ファイルcandleを実行し、次に WiX ユーティリティを呼び出しlightて実際のセットアップをビルドします。
  • candleこの.wxsファイルを使用してセットアップを作成します。ここでも、環境変数からバージョン番号を取得します。$(env.VersionNumber)
  • .msiによって作成された最終的なファイルには、ファイル名(バージョン番号を含む環境変数を含む)を引数としてlight渡すため、ファイル名にバージョン番号が含まれます。-out release\msi\bitbucket-backup-%VersionNumber%.msi

最初はすべてを理解するのに時間がかかりましたが、今ではすべてのプロジェクトを同様の方法でリリースしています。

于 2013-05-09T11:07:59.763 に答える