我处于快乐的情况(</sarcasm>），我在这里处理包含168个项目的Visual Studio 2012解决方案。
我们正在大约15个工作，其他的我们不接触。
当我们对整个解决方案进行代码分析时，运行23分钟，这有点长......
但是，当我们必须弄清楚哪些项目被触及时，这也是一个痛苦，所以我们只能对那些项目进行代码分析。
所以问题是，是否可以创建一组自定义项目来运行代码分析？
答案 0 :(得分：4)
简单地说，Visual Studio没有办法在解决方案的项目子集上运行其代码分析工具。
但是，您可以考虑一些可能的解决方法。
将活动项目解压缩为单独的解决方案：
创建一个新的空白解决方案，将所有现有活动项目添加到其中，并在较小的解决方案上运行代码分析。由于项目文件相同，解决方案将同步。如果这些项目依赖于非活动项目，可能会提供虚假报告。
对非活动项目使用空规则集：
添加“代码分析规则集”类型的新文件，编辑它，在其“属性”窗口中将其名称更改为“无规则”，然后取消选中所有规则（如果有任何规则）。
然后转到解决方案属性，选择“公共属性 - >代码分析设置”，并将非活动项目的所有规则集更改为“无规则”。您可以通过306次点击完成此操作。
这将为代码分析提供最佳运行时间，但也会使用CA0064: No analysis was performed because the specified rule set did not contain any FxCop rules.
填充结果窗口对非活动项目使用简单的规则集：
如上所述，但随后将任何一条规则添加到您根本不希望看到的“无规则”中。这将使代码分析变慢（但仍然比使用实际规则集快得多），您将不再收到警告CA0064。
说实话，Visual Studio的内置代码分析存在一些基本缺陷，我建议使用专业的外部工具，如ReSharper，或其他评论中建议的工具。使用空/普通规则集当然应该达到所需的结果，但它更像是一种解决方法而不是实际的解决方案。
答案 1 :(得分：1)
如果您不愿意重新访问您的解决方案方法（与其他人一样，我强烈建议），多种解决方案构建配置可能是在各种情况下为代码分析启用不同组件集的最简单方法。例如，您可能希望考虑一组解决方案配置，如下所示（其中“核心”项目是您通常使用的15个）：
（如果您愿意对项目配置有点看中，那么将项目级配置的相关部分外部化到导入的MSBuild .targets文件将使得管理所有这些更简单，特别是考虑到受影响的数量项目。）
对于大多数日常活动，大多数开发人员可能会选择在DebugNoBuild或DebugCompileOnlyCore下工作，并且可以选择Debug或DebugCore（如您所愿）以进行预提交规则验证。通常，我建议使用完整的Debug（带有所有相关的静态分析）来进行持续集成构建，但考虑到完整分析的持续时间，这可能在您的情况下不实用。如果您正在使用CI，最好使用DebugCore（或编译所有内容的变体，但只对核心项目运行静态分析）进行CI构建，然后添加一个比每天更频繁运行的定期调度构建（比如每个一两个小时）运行使用完整Debug配置的构建。
答案 2 :(得分：0)
您可以从外部构建文件（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>
可以使用外部工具从visual studio内部运行脚本（如果你的团队不喜欢shell）。
希望这有帮助。