7

誰かが私のソリューションを構築するときに、ソリューションの構成に応じて、実行したい複数のタスクがあります。

  • リリース構成で、ソリューション全体に対して Doxygen を実行します (doxygen.exe ....)
  • デバッグおよびリリース構成で、ソリューション全体に対して StyleCop を実行します (StyleCop ターゲットを呼び出します)。
  • デバッグ構成で、ソリューション全体に対して FxCop を実行します (fxcop.exe ...)
  • もっと

これらはすべてソリューション レベル (グローバル) のタスクであるため、これをすべてのプロジェクト ファイルに入れるのは意味がありません。これは一般的な問題のように思えますが、どのように対処しますか?

空のプロジェクトを作成し、他のすべてのプロジェクトがそれに依存していることを確認し、その中にすべてのソリューション レベルのタスクを配置できると考えています...?

4

5 に答える 5

3

これを行う最も簡単な方法は、"Build.csproj" という名前の空のプロジェクトを作成することです。ソリューションに配置し、他のすべてのプロジェクトに依存させます。次に、単純なタスクの場合、ビルド後のイベントを使用してツールを実行できます。さらに高度にする必要がある場合は、プロジェクトのビルド ターゲットを変更できます。

それにはいくつかの良い点があります。

  1. シンプルでセットアップも理解も簡単です。
  2. 別のプロジェクトをスタートアップとして設定するため、通常はデバッグに干渉しません。
  3. プロジェクトを無視する構成を作成できます。
  4. ポストビルドイベントに固執すると仮定すると、警告なしで VS 統合が可能になります。
于 2012-10-25T14:31:41.173 に答える
3

この質問は、毎回すべてをビルドする必要があることを前提としていますが、実際にはそうではありません。現在、私が一緒に働いているチームは、ビルド時間に非常に敏感です。

そのため、ビルドを 1 つのものとしてではなく、複数のフレーバーを持つものと見なすことをお勧めします。「それは構築されますか？」があります。リシェイパーを使い始めるまでは、Build Selection (現在のプロジェクトのみ) をキーにマップしていました。単体テストを行っていない人 (テスト不可能な UI の変更を開発している人を含む) のための「ビルドをテストしてみましょう」があり、もちろん、ドキュメント、stylecop、およびその他のメトリックを作成できる「すべてとキッチン シンク ビルド」があります。得られた。

このため、ビルド サーバーの使用をお勧めします。追加のターゲットを邪魔にならないようにして、他のすべての作業が完了したらそれらを使用してください。TeamCity の事前テスト済みのコミット機能は、チームが壊れないことをテストし、カバレッジの低下などの障害条件を構築できるようにする優れた方法としてお勧めします。

また、開発時にさらに迅速なビルドを探している場合は、ファイルを編集してから 1 秒ほどで実行される高度に最適化されたビルド プロセスを備えた NCrunch、または ContinuousTests の使用をお勧めします。

于 2012-10-25T08:18:54.710 に答える
3

私は、そのようなタスクを .targets ファイルに入れ、メイン プロジェクト (ライブラリを作成していないプロジェクト) からそれらを参照することを好みます。Targetまた、一般的なタスクのサブセットを結合する .targets ファイルに を作成することもあります。そうすれば、いくつかのプロジェクトは便利にsharedtask1andsharedtask2を実行できますが、他のプロジェクトはsharedtask1andを実行します。sharedtask3DependsOnTargets="Shared12"DependsOnTargets="Shared13"

これらの記事には、msbuild タスクを整理するための良いアドバイスがあります。

信頼できるビルドを作成するためのベスト プラクティス、パート 1

信頼できるビルドを作成するためのベスト プラクティス、パート 2

編集

一部のタスクを 1 回だけ実行するには、上記の 2 番目の記事で説明されているように、インクリメンタル ビルドを使用します。

  • 上記で示唆した共通の .targets ファイルで、すべてのファイルを入力として、いくつかのダミー マーカー ファイルを出力として持つタスクを作成します。
  • そのタスクに関心のある実際の作業を実行させ、マーカー ファイルを更新します。
  • すべてのプロジェクトが新しく作成されたタスクに依存するようにする

ソリューションがビルドされると、最初のプロジェクトが上記のタスクを開始し、タスクはマーカー ファイルを出力します。ビルドの残りの部分で入力ファイルが変更されない限り、そのタスクは再度実行されません。 . さて、これの欠点は

  • ビルドの過程でファイルが生成または変更される場合、タスクは複数回実行されます。
  • 単一のプロジェクトのビルドのみを実行している場合でも、タスクは実行されます。ドキュメントを生成している場合、これは実際には「正しい」動作である可能性があります。それを避けたい場合は、msbuild ファイルを本当に微調整する必要があると思いますが、それが回避しようとしているという印象を受けます。
  • タスクはビルドされる前に実行されるため、アセンブリのビルドされるバージョンに依存するタスクはうまくいきません。

最後の問題に対処するには、VS からのビルドをあきらめ、代わりにコマンド ラインから msbuild.exe を使用して、ソリューションをビルドし、1 つまたは複数のカスタム タスクを順番に実行するカスタム タスクを呼び出す必要があります。おそらくあなたが求めている開発者体験ではないことを私は理解しています.

于 2012-10-23T08:14:59.220 に答える
1

私たちのソリューションでは、そのようなビルド アクションをスタートアップ プロジェクトに配置しました。これは、すべてのプロジェクトに配置したくないためであり、実行中のプロジェクトは他のすべてのプロジェクトを参照します。したがって、このプロジェクトのビルド後のアクションで実行されるすべてのアクションは、他のすべてのプロジェクトが既に完了した後に実行されます。

于 2012-10-28T05:00:57.277 に答える
1

何か足りないかもしれませんが、選択したターゲットでビルド フォローアップ タスクを実行するさまざまなスクリプトを含むソリューション フォルダーを作成し、それらをプロジェクトのビルド後のイベントから呼び出してみませんか? いえ

  • PostBuildScripts (ソリューション フォルダー)
    • FxCop.Debug.Target
    • FxCop.Release.Target
    • StyleCop.Release.Target
    • StyleCop.Release.Target
    • Doxygen.Debug.Target
    • Doxygen.Release.Target
    • その他.リリース.ターゲット
    • その他.リリース.ターゲット

...など...

これらのスクリプトは、ターゲット ビルド タイプに対してフォローアップ タスクを実行するための呼び出しを行います。実際に特定のビルド タイプに対して実行したくない場合は、空のままにしてください。

プロジェクトでポストビルド:

/PostBuildScripts/FxCop.$(ConfigurationName).Target

/PostBuildScripts/Doxygen.$(ConfigurationName).Target

/PostBuildScripts/StyleCop.$(ConfigurationName).Target

/PostBuildScripts/Others.$(ConfigurationName).Target

...など...

于 2012-10-25T17:26:59.263 に答える