Can I run Visual Studio Code Analysis in a custom set of projects?

Question

I am in a happy situation (</sarcasm> ) where I am working on a Visual Studio 2012 solution containing 168 projects.

We work in about 15 of them, while others do not touch.

When we run code analysis on the whole solution, it works for 23 minutes, and it is a little longer .....

But it’s also a pain when we have to analyze each check which projects were affected, so we can run code analysis only for those projects.

So, the question is, is it possible to create your own set of projects to perform code analysis on?

Answer 1

Simply put, Visual Studio is not able to run its code analysis tool in a subset of the projects in the solution.

However, there are several possible workarounds that you might consider.

---

Extract active projects into a separate solution:

Create a new blank solution, add all existing active projects to it, and run code analysis for a smaller solution. Solutions will be synchronized because the project files are the same. You can give false reports if these projects depend on inactive projects.

---

Use an empty rule set for inactive projects:

Add a new file of the “Code Rule Set” type, edit it, change its name to “No rules” in its “Properties” window and clear all the rules (if checked).

Then go to the properties of your solution, select "General Properties → Code Analysis Settings" and change all the rules for inactive projects to "No Rules". You can do it in 306 clicks.

This will give better execution time for code analysis, but it will also flood the result window with CA0064: the analysis was not performed because the specified rule set did not contain any FxCop rules.

---

Use the trivial rule set for inactive projects:

As above, but then add any one rule to "No Rules" that you do not expect to see at all. This will make code analysis slower (but still much faster than using the actual rule set) and you will no longer receive warning CA0064.

---

To be completely honest, Visual Studio's built-in code analysis has some fundamental flaws, and I would recommend using a professional external tool like ReSharper, or the tools suggested in other comments. Using an empty / trivial set of rules must necessarily provide the desired result, but this is more a workaround than an actual solution.

Answer 2

If you do not want to rethink the solution approach (which, like others, I would highly recommend), several solution assembly configurations would probably be the easiest way to include different sets of assemblies for code analysis in different scenarios. For example, you can consider a set of solution configurations similar to the following (where the “main” projects are 15 that you usually work on):

• Debug
  • All projects: compilation (debugging configuration) and launch of static analysis (VS Code Analysis / FxCop, StyleCop, application of architecture rules, etc.).
• Debugcore
  • Main projects: compilation (debugging configuration) and launch of static analysis
  • Other projects: do not compile or run static analysis
• DebugCompileOnlyCore
  • Main projects: Compilation (debugging configuration), but not performing static analysis.
  • Other projects: do not compile or run static analysis
• DebugNoBuild
  • All projects: do not compile or run static analysis
• Release
  • All projects: compilation (release configuration) and running static analysis, if you decide to do this for release configurations

(If you want to get a little involved in project configurations, externalizing the corresponding parts of the project-level configurations for the imported MSBuild.targets files will make it all a lot easier, especially considering the number of affected projects.)

Most developers will probably want to work in DebugNoBuild or DebugCompileOnlyCore for most of their daily activities, and Debug or DebugCore (at your discretion) can be chosen to check the pre-commit rules. I usually recommend using full Debug (with all the relevant static analyzes) for continuous integration builds, but this may not be practical in your case, given the length of the full analysis. If you use CI, it’s best to use DebugCore (or an option that compiles everything, but only runs static analysis on major projects) to build CI, and then add a regularly scheduled build that runs more often than daily (say, every hour or two ) to run a build that uses the full Debug configuration.

Answer 3

You can easily do this from an external assembly file (build.proj - in the solutions directory):

 <?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> 

• Building without code analysis.
• Only analyze selected projects.
• You can refer to another script with a list of the analyzed projects if each developer uses a different set of projects. This one will not be included in VCS.

You can run the script from the internal visual studio using external tools (if your team does not like the shell).

Hope this helps.