私たちのプロジェクトでは、コード品質ツールとして FxCop に大きく依存しています。最近、プロジェクトを 8 つのモジュールから 30 以上のモジュール (MS 用語で「プロジェクト」) に分割しました。それ以来、コード分析 (FxCop) を有効にしたビルド時間は爆発的に増加しました。
モジュールごとに FxCop を繰り返し起動すると、ビルド全体にかなりのオーバーヘッドがかかることは明らかです。開発者にとってこの煩わしい体験を改善するヒントはありますか?
私たちのプロジェクトでは、コード品質ツールとして FxCop に大きく依存しています。最近、プロジェクトを 8 つのモジュールから 30 以上のモジュール (MS 用語で「プロジェクト」) に分割しました。それ以来、コード分析 (FxCop) を有効にしたビルド時間は爆発的に増加しました。
モジュールごとに FxCop を繰り返し起動すると、ビルド全体にかなりのオーバーヘッドがかかることは明らかです。開発者にとってこの煩わしい体験を改善するヒントはありますか?
この種のことに対する私の好ましいアプローチは、静的分析が無効になっているソリューションにビルド構成を追加することです(例:「デバッグ(コンパイルのみ)」)。開発者は、共有ソース管理にコミットする前に、完全な「デバッグ」構成でビルドする必要がありますが、ルーチンのローカル ビルドにこれを使用することを選択できます。(理想的には、継続的インテグレーション ビルドでは、完全なスクリーニングを実行して、失敗を検出します。)
別のオプションは、プロジェクトごとのコード分析構成を削除し、代わりにすべてのアセンブリに対して fxcopcmd.exe を一緒に呼び出すことです。残念ながら、これをトリガーする場所を特定することは、コマンド ラインを設定するよりもややこしいことです。トップレベルの実行可能ファイルが 1 つしかない場合、そのビルドは適切な候補となる可能性があります。