2

単一のTFSソリューション（シェル、comonライブラリ、2つのモジュール、およびいくつかのテストプロジェクト）にPRISMアプリがあります。簡単にするために、DirectoryModuleCatalogを選択し、ビルド後にアプリをローカルで実行するために、コピーしたモジュールプロジェクトビルドにビルド後の手順を追加しました。 GUIアプリの出力パスのmodulesサブフォルダーへのビルドdll。

これはローカルクライアントビルドでは問題なく機能しますが、同じポストビルドイベントがTFSビルドエージェントからトリガーされると失敗します。検査では、これは、ローカルで相対パスである$（OutDir）マクロが、TFSビルドエージェントのMSBuildログの絶対パスであるためです。

MSDNを引用するには

$(OutDir) 

Path to the output file directory, relative to the project directory. 
This resolves to the value for the Output Directory property. 
It includes the trailing backslash '\'.

ローカルでは、これはビルドエージェントの「bin \ Debug」に解決され、「C：\ Builds \ 5 \ XXXX \ Gui.DEV_XXXX7_Iteration0.CI \Binaries\」に解決されます。

この元のローカルのビルド後の定義を考えると、

mkdir "$(SolutionDir)Gui\$(OutDir)Modules\"
copy "$(TargetPath)" "$(SolutionDir)Gui\$(OutDir)Modules\"

次のようなビルドエージェントで失敗する理由がわかります。

mkdir "C:\Builds\4\XXXX\Gui.DEV_Cortex7_Iteration0.CI\Sources\Gui\C:\Builds\4    \XXXX\Gui.DEV_XXXX7_Iteration0.CI\Binaries\Modules\"
copy "C:\Builds\4\XXXX\Gui.DEV_XXXX7_Iteration0.CI\Binaries\Apdcomms.Cortex.Gui.Example2.Module.dll" 
    "C:\Builds\4\XXXX\Gui.DEV_XXXX7_Iteration0.CI\Sources\Gui\C:\Builds\4\XXXX\Gui.DEV_XXXX7_Iteration0.CI\Binaries\Modules\"
The filename, directory name, or volume label syntax is incorrect.
The filename, directory name, or volume label syntax is incorrect.
      0 file(s) copied.

そのため、マクロの値を確認すると、TFSビルドエージェントでローカルモードのコマンドとは異なるコマンドのセットがポストビルドで必要になるように見えますが、これはかなり厄介です。

SO to the qestion：loclaクライアントビルドとTFSチームビルドで機能する方法で、ソリューション内の1つのプロジェクトのバイナリ出力を同じソリューション内の別のプロジェクトのサブフォルダーに移動するにはどうすればよいですか？

4

1 に答える 1

2

私は個人的に、TFSからビルドするときにビルド後のスクリプトに依存するのは好きではありません。ビルドテンプレートをカスタマイズする方がはるかに良いでしょう。ビルド後のスクリプトは確かに簡単ですが、ビルドテンプレートは（私の意見では）環境をより適切に管理します。これを実現する方法についてもう少し情報を提供するために、Microsoftの記事にリンクしています。StackOverflowが自己完結型を維持できるように、コンテンツも貼り付けています。

http://msdn.microsoft.com/en-us/library/ff977206.aspx

デフォルトのビルドプロセス（DefaultTemplate.xamlで定義されている）は、コンパイルするバイナリをすべてのコードプロジェクトから単一のディレクトリにドロップします。ただし、場合によっては、バイナリをよりきめ細かく整理されたフォルダ構造に整理する必要があります。

このトピックの手法を使用して、バイナリを設計したディレクトリ構造にドロップするカスタムビルドプロセスを作成できます。同じ原則を使用して、さまざまな方法でビルドプロセスをカスタマイズすることもできます。このトピックでは、次の手法について説明します。

ビルドプロセスのWindowsワークフローセグメントをカスタマイズします。バイナリのコンパイルと処理を除いて、ビルドプロセスのほとんどの側面をカスタマイズするには、このセグメントに変更を加える必要があります。具体的には、このトピックでは、次のタスクを実行する方法について説明します。

デフォルトテンプレート（DefaultTemplate.xaml）のコピーを変更して、カスタムビルドプロセスを作成します。

引数を宣言して使用し、ワークフローにデータを渡します。

変数を宣言して使用し、ワークフロー全体でデータを収集して渡します。

ワークフローがMSBuildアクティビティを使用してMSBuildを呼び出す方法を変更します。

ビルドサーバーにファイルをダウンロードし、ConvertWorkspaceItemアクティビティを使用して、そのファイルをビルドプロセスで使用できるようにします。

ビルドプロセスのMSBuildセグメントをカスタマイズします。このセグメントに変更を加えることで、バイナリのコンパイル方法と処理方法をより効果的にカスタマイズできます。具体的には、このトピックでは、次のタスクを実行する方法について説明します。

引数をMSBuildに渡し、コードプロジェクトでそれらを使用して、コンパイルされたバイナリの処理方法を変更します。

プロパティグループやターゲットなど、独自のMSBuild要素の一元化された共通コードライブラリをセットアップします。このタイプのライブラリを設定することにより、チームがビルドプロセスロジックの重要な部分を簡単に再利用および変更できるようになります。

于 2012-05-31T17:07:35.847 に答える