5

静的 CA は、ソリューションのビルドを大幅に遅くします。私の場合、CA を使用しない場合よりも 2 倍以上遅くなります。無効にすることはできますが、それはその力を失うという悪い決断です。では、何ができるでしょうか？

まず、CA の仕組みを見てみましょう。

ソリューションを構築します。msbuild コンパイル ターゲット fxcopcmd.exe 後の各プロジェクト ビルドで、分析する必要があるアセンブリへのパスを使用して呼び出されます。fxcopcmd. VS (または出力ストリーム) で使用される CA xml ログを生成します。fxcopcmd.exe はアセンブリ (高速) を読み込み、その同期を分析するため、読み込まれる CPU は 1 つだけで、3 つ (私の場合) は何もしていません。CA が終了した後にのみ、プロジェクトの依存関係チェーンの次のプロジェクトが構築されます。

したがって、CA の弱点は、すべての CPU を使用するように強制的に並行して動作させることです。

私はそのような解決策を見ます

MSBUILD からパラメーターを取得する偽の fxcopcmd.exe を作成するには、それを覚えておいて、すぐに msbuild にすべて問題なく、エラーがないことを報告します (CA xml.log、成功したファイル、またはストリームなどを介して)。したがって、MSBUILD は次のプロジェクトをビルドし、その時点で、保存されたパラメーターを使用して実際の fxcopcmd.exe を呼び出します... MSBUILD が次のプロジェクトで fxcopcmd.exe を呼び出す場合、もう一度 fxcopcmd.exe を呼び出します...すべての CPU をロードするプロセスはほとんどありません。本物の fxcopcmd.exe が終了したら、MSBUILD ターゲットを呼び出して、コンパイルせずに microsoft.common.targtets から CA ターゲットのみを呼び出すことができます。偽の fxcopcmd.exe は即座に結果を報告します (CA はその時点で終了し、ログがあります)。 MSBUILD-VS に。

どう思いますか？これは CA を高速化しますか? Microsoft がそのようなスタッフを作成せず、CA で 1 つの CPU のみを使用したのはなぜですか?

4

1 に答える 1

4

Connect で同様の質問をしたことがありますが、チームから直接返信がありました。2012 年の ALM サミットで私はこのトピックについて議論しましたが、いくつかの理由がありました (順不同)。

  • プロジェクト Roslyn が Visual Studio 製品に統合されると、コード分析エンジンが置き換えられる可能性が高くなります。Roslyn は、リアルタイム分析 (Resharper など) と、見つかった問題を「修正」する機能を提供します。
  • エンジンは非常に CPU を集中的に使用し、すでに複数の CPU を使用しているため、複数のインスタンスを実行しても、思ったほど役に立たないかもしれません。また、fxcop は非常に I/O 集約的 (アセンブリ、pdb、およびその他のファイルのロード) になる可能性があり、複数のインスタンスを同時にロードすると悪化するだけです。
  • ビルド エンジンはビルド出力にアクセスする必要があります。参照用だけでなく、他のタスクにも使用できます。したがって、タスクが終了したときにファイルが使用されていないことを知る必要があります。たとえば、後で古いアセンブリを削除する多数のアセンブリを IlMerges するタスクを追加する場合、それらのファイルにアクセスする必要があります。単純な移動/パッケージ/その他のアクションについても同じことが言えます。
  • コード分​​析の問題 (level=error に設定) が見つかったときにビルドを早期に失敗させる機能は機能しません。これは、結果を最後に収集するだけであるためです。最終結果を使用できないことを知るためだけに、すべてを構築する可能性があります。

この MSDN フォーラムの投稿でわかるように、Fxcop 自体は既に複数のスレッドを使用しており、(少なくとも 2010 で出荷されたルールでは) 同時実行に関するいくつかの問題が既に存在し、特定のケースで Fxcop の同時実行を無効にする原因となっています。fxcop でより多くの (またはより少ない) スレッドを使用する場合は、fxcopcmd.exe.configファイルを編集できます。

 <FxCopEngineSettings Version="1.32">
   <Engines>
     <Engine Name="Introspection" Enabled="True">
       <!-- Change this number to use more (or fewer) threads -->
       <Threading Count="1" />
       <EnableFlowAnalysis>True</EnableFlowAnalysis>
     </Engine>
   </Engines>
 </FxCopEngineSettings>

フォーラムの投稿では Visual Studio 2008 について言及されていますが、これを適用して 2010 の問題も修正しました。

FxCop をより効率的にする最も簡単な方法は、すべてのプロジェクトがコンパイルされた後に一度呼び出すことです。これにより、すべてのシンボルと参照されたアセンブリが 1 回だけ読み込まれ、エンジンが並列処理を最大限に活用できるようになります。複数のターゲット プラットフォームと CPU を混在させるソリューションがある場合、またはプロジェクトごとに異なる .rules ファイルを使用する場合にも、いくつかの問題があります。

または、ローカル ソリューション用に FxCop を構成するという、私と同じことを行うこともできますが、ビルドごとに実行するように設定することはできません。次に、Team Foundation Server チーム ビルド (または使用するその他のビルド サーバー) で、FxCop の構成を上書きして "常に" 実行します。そうすれば、ローカル ソリューションの構築中にパフォーマンスに影響を与えることはありません。それでも、ソリューション全体のコード分析をローカルで ([分析] メニュー項目から) 実行でき、自動ビルドにより、問題のあるコードのチェックインを防ぐことができます。

于 2013-05-26T16:00:30.883 に答える