コード解析の改善

Question

静的CAは、ソリューションの構築をより遅くします。私の場合は、CAを使わない場合より2倍以上遅くなります。我々はそれを無効にすることができますが、それはその力を失うことは悪い決定です。 どうすればいいですか？

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

ソリューションを構築します。 msbuildの後にビルドされる各プロジェクトで、コンパイル対象fxcopcmd.exeが解析対象のアセンブリへのパスとともに呼び出されます。 fxcopcmd。 VS（または多分出力ストリーム）によって使用されるCA xmlログを生成します。 fxcopcmd.exeはアセンブリを高速に読み込んで同期的に解析するので、1つのCPUのみがロードされ、3つの場合は何もしません。 CAが完了した後でのみ、プロジェクト依存関係チェーンの次のプロジェクトが構築されます。

したがって、CAの弱い場所では、すべてのCPUを使用するよう並列に動作させることができます。

が、私はこのようなソリューションを参照

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

あなたはどう思いますか？これはCAのスピードアップでしょうか？ なぜマイクロソフトはそのようなスタッフを作らず、CAでCPUを1つだけ使用しましたか？

Answer 1

私は一度similar question on Connect and got a reply directly from the teamと尋ねました。 2012年にALMサミットで、私は、トピックを議論し、プロジェクトRoslynのは、Visual Studio製品に統合されたら、コード分析エンジンは、最も可能性の高い置き換えられます

• （順不同）多くの理由がありました。 Roslynは、Resharperのようなリアルタイム分析と、見つかった問題を修正する機能を提供します。
• エンジンはCPUを大量に使用しており、複数のCPUをすでに使用しているため、複数のインスタンスを実行すると、疑わしいほど多くのヘルプが表示されないことがあります。また、fxcopは非常にI/O集約型（アセンブリ、pdb、その他のファイルの読み込み）で、複数のインスタンスを同時に読み込むと悪化することがあります。
• ビルドエンジンはビルド出力にアクセスする必要があります。参照するだけでなく、他のタスクも参照します。したがって、タスクが終了したときにファイルが使用されなくなったことを知る必要があります。たとえば、あとで古いものを削除する多数のアセンブリをIlMergesするタスクを追加すると、それらのファイルにアクセスする必要があります。単純な移動/パッケージ/ etcアクションでも同じです。
• コード解析の問題（レベル=エラーに設定されている）が見つかったときにビルドを早く失敗させる機能は、結果を最後に集めるだけなので、機能しません。あなたが最終結果を使用することができないことを知るためにのみ、すべてを構築する可能性があります。

あなたはthis MSDN forum postここで見ることができるように、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をより効率的にする最も簡単な方法は、すべてのプロジェクトをコンパイルした後に一度呼び出すことです。これにより、すべてのシンボルと参照されたアセンブリのみを一度ロードし、エンジンが並列性を最大限に活用できるようになります。複数のターゲットプラットフォームとCPUを混在させるソリューションがある場合や、異なるプロジェクトに異なる.rulesファイルを使用する場合は、この問題にいくつかの問題があります。

また、FxCopをローカルソリューション用に構成することもできますが、各ビルドで実行するように設定することはできません。次にTeam Foundation Server Team Build（または使用する他のビルドサーバー）で、FxCopの構成を "Always"を実行するように変更します。そうすれば、ローカルソリューションを構築する際にパフォーマンスに影響を与えることはありません。これにより、ソリューション全体のコード解析をローカル（Analyzeメニュー項目から）で実行することができ、自動ビルドでは問題のあるコードのチェックインを防ぐことができます。