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

Question

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

We are working in approximately 15 of them, and the other ones we do not touch.

When we run code analysis on the entire solution it runs for 23 minutes, and that's a bit long.....

But it's also a pain when we have to figure out on each checkin which projects were touched so we can run code analysis for only those projects.

So the question is if it's possible to create a custom set of projects to run code analysis on?

Answer 1

Simply put, Visual Studio doesn't have a way of running its code analysis tool on a subset of the projects in a solution.

However there are a few possible workarounds you could consider.

---

Extract the active projects into a separate solution:

Create a new blank solution, add all of the existing active projects to it, and run code analysis on the smaller solution. The solutions will be in sync as the project files are the same. Might give false reports if those projects depend on inactive projects.

---

Use an empty ruleset for inactive projects:

Add a new file of type "Code Analysis Rule Set", edit it, change its name to "No Rules" in its Properties window, and uncheck all of the rules (if any are checked).

Then go to your solution properties, select "Common Properties -> Code Analysis Settings", and change all the rulesets for inactive projects to "No Rules". You can do this in 306 clicks.

This will give the best runtime for code analysis, but will also flood the results window with CA0064: No analysis was performed because the specified rule set did not contain any FxCop rules.

---

Use a trivial ruleset for inactive projects:

As above, but then add any one rule to "No Rules" that you don't expect to see at all. This will make code analysis slower (but still much faster than using an actual ruleset) and you will no longer get warning CA0064.

---

To be perfectly honest, Visual Studio's in-built code analysis has some fundamental flaws and I would recommend the use of a professional external tool such as ReSharper, or tools suggested in other comments. Using an empty/trivial ruleset should certainly achieve the required result, but it's more of a workaround than an actual solution.

Answer 2

If you're unwilling to revisit your solution approach (which, like others, I would strongly recommend), multiple solution build configurations would probably be the simplest way to enable different sets of assemblies for code analysis under various scenarios. For example, you may wish to consider a set of solution configurations like the following (where "core" projects are the 15 you usually work on):

1. Debug
   • All projects: compile (debug configuration) and run static analysis (VS Code Analysis/FxCop, StyleCop, architecture rule enforcement, etc.)
2. DebugCore
   • Core projects: Compile (debug configuration) and run static analysis
   • Other projects: Do not compile or run static analysis
3. DebugCompileOnlyCore
   • Core projects: Compile (debug configuration) but do not run static analysis
   • Other projects: Do not compile or run static analysis
4. DebugNoBuild
   • All projects: Do not compile or run static analysis
5. Release
   • All projects: compile (release configuration) and run static analysis if you choose to do so for release configs

(If you're willing to go a bit fancy on project configurations, externalizing the relevant parts of the project-level configurations to imported MSBuild .targets files would make managing all of this across much simpler, particularly given the number of affected projects.)

Most developers would probably choose to work under DebugNoBuild or DebugCompileOnlyCore for most of their day-to-day activities, and Debug or DebugCore (as you deem appropriate) could be selected for pre-commit rule verification. Normally, I'd recommend using full Debug (with all relevant static analyses) for continuous integration builds, but that may not be practical in your case given the duration of the full analysis. If you are using CI, it might be best to use DebugCore (or a variant that compiles everything but only runs static analysis over the core projects) for the CI build, then add a regularly scheduled build that runs more frequently than daily (say every hour or two) to run a build that uses the full Debug configuration.