代码分析改进

Question

静态CA使解决方案构建mutch更慢。在我的例子中，比没有CA的速度慢2倍。我们可以使它失效，但这是失去它的力量的错误决定。那我们能做什么呢？

首先让我们看看CA是如何工作的.

你建立解决方案。在每个项目中，在msbuild之后构建编译目标，将使用程序集的路径调用fxcopcmd.exe，应该对这些路径进行分析。fxcopcmd.生成由VS (或可能输出流)使用的CA日志。fxcopcmd.exe加载程序集(Fast)并对其进行同步分析，因此只加载了一个CPU，而3个CPU(在我的例子中)什么也不做。只有在CA完成后，项目依赖链中的下一个项目才会被构建。

所以CA的弱点在于我们可以改进它--迫使它并行地使用所有CPU。

我看到这样的解决方案

要制作将从MSBUILD获取参数的假fxcopcmd.exe，请记住它，并立即向msbuild报告一切正常且没有错误(通过CA xml.log、成功文件或流.)。因此MSBUILD将构建下一个项目，届时我们将使用保存的参数调用真正的fxcopcmd.exe .如果MSBUILD将在下一个项目中调用fxcopcmd.exe -我们将再调用一次fxcopcmd.exe.在真正的fxcopcmd.exe完成后，我们可以调用我们的MSBUILD目标，它只从microsoft.common.targtets调用CA目标，不需要编译，我们的假fxcopcmd.exe将立即向MSBUILD报告结果(CA已经完成，我们有日志)。

你认为如何？这能加快CA的速度吗？为什么微软不做这样的工作人员，在CA中只使用一个CPU？

Answer 1

我曾经问过一个关于连接的类似问题，并直接得到了团队的答复。在2012年的ALM首脑会议上，我讨论了这个问题，有许多原因(没有具体的顺序)

• 一旦Project集成到Visual产品中，代码分析引擎很可能会被替换。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 2008，但我也将此应用于修复2010年的问题。

要提高FxCop的效率，最简单的方法是在编译完所有项目之后调用它一次。这将导致它只加载所有符号和引用的程序集一次，并允许引擎最大限度地使用并行性。当您有一个将多个目标平台和cpu混合在一起的解决方案时，或者当您想要为不同的项目使用不同的.rules文件时，也会出现一些问题。

或者您也可以做我所做的事情，即为您的本地解决方案配置FxCop，但不将其设置为在每个构建上运行。然后在(或您可能使用的任何其他构建服务器)中，重写FxCop运行“始终”的配置。这样，在构建本地解决方案时，就不会对性能产生影响。它仍然允许您在本地(从分析菜单项)运行整个解决方案的代码分析，并且自动构建可以防止您签入带有问题的代码。