简而言之，Visual Studio无法对解决方案中的项目子集运行其代码分析工具。
但是，您可以考虑一些可能的解决方法。

将活动项目提取到单独的解决方案中：

创建一个新的空白解决方案，向其中添加所有现有的活动项目，然后对较小的解决方案运行代码分析。由于项目文件相同，因此解决方案将同步。如果这些项目依赖于非活动项目，则可能会给予错误的报告。

对非活动项目使用空规则集：

添加一个类型为“代码分析规则集”的新文件，编辑它，在其“属性”窗口中将其名称更改为“无规则，”然后取消选中所有规则（如果选中了任何规则）。
然后转到你的解决方案属性，选择“公共属性-〉代码分析设置”，并将所有不活动项目的规则集改为“无规则”。你可以在306次点击中完成这件事。
这将为代码分析给予最佳运行时，但也会使结果窗口充斥CA0064: No analysis was performed because the specified rule set did not contain any FxCop rules.

对非活动项目使用普通规则集：

如上所述，但是添加任何一个你不希望看到的规则到“No Rules”中，这会使代码分析变慢（但仍然比使用实际的规则集快得多），并且你不会再收到警告CA 0064。
老实说，Visual Studio的内置代码分析有一些根本性的缺陷，我建议使用专业的外部工具，如ReSharper，或者其他评论中建议的工具。使用空的/琐碎的规则集当然应该达到所需的结果，但它更多的是一种变通方法，而不是实际的解决方案。

如果您不愿意重新审视您的解决方案方法（像其他人一样，我强烈推荐），多个解决方案构建配置可能是在各种场景下启用不同程序集进行代码分析的最简单方法。例如，您可能希望考虑一组解决方案配置，如下所示（其中"核心"项目是您通常处理的15个项目）：

• 调试
• 所有项目：编译（调试配置）并运行静态分析（VS代码分析/FxCop、StyleCop、架构规则实施等）
• 调试核心
• 核心项目：编译（调试配置）并运行静态分析
• 其他项目：不编译或运行静态分析
• 调试仅编译内核
• 核心项目：编译（调试配置）但不运行静态分析
• 其他项目：不编译或运行静态分析
• 调试无生成
• 所有项目：不编译或运行静态分析
• 放行
• 所有项目：编译（发布配置）并运行静态分析（如果您选择为发布配置这样做）

(If您愿意对项目配置进行一些花哨的处理，将项目级配置的相关部分外部化到导入的MSBuild.targets文件将使管理所有这些内容变得简单得多，特别是考虑到受影响的项目数量。）
大多数开发人员可能会选择在DebugNoBuild或DebugCompileOnlyCore下进行大多数日常活动，而Debug或DebugCore（如果你认为合适的话）来进行预提交规则验证。（以及所有相关静态分析），用于持续集成构建，但考虑到完整分析的持续时间，这在您的情况下可能不实用。如果您正在使用CI，最好使用DebugCore（或编译所有内容但仅在核心项目上运行静态分析的变体），然后添加一个比每天运行更频繁的定期构建（比如每隔一两个小时），以运行使用完整Debug配置的构建。

您可以从外部构建文件（build.proj -位于解决方案的目录中）轻松完成此操作：

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="Build">
    <MSBuild Projects="TestSolution.sln" Properties="RunCodeAnalysis=false"></MSBuild>
    <MSBuild Projects="ClassLibrary1\ClassLibrary1.csproj" Targets="RunCodeAnalysis"></MSBuild>
    <MSBuild Projects="ClassLibrary2\ClassLibrary2.csproj" Targets="RunCodeAnalysis"></MSBuild>
  </Target>
</Project>

1.生成而不进行代码分析。
1.仅对选定项目运行分析。
1.你可以引用另一个脚本来分析项目列表，以防每个开发者使用不同的项目集。这个脚本不会进入VCS。
可以使用外部工具从visual studio内部运行脚本（如果您的团队不喜欢shell）。
希望这个有用。

请尝试CTRL+SHIFT+P -〉搜索reanalyze project。