Don't let code analysis slow you down.

Given the chance, code analysis will drain your time and slow you down. As a developer I like to have my environment run the way I like and I like compiles to be as fast as possible.

Code analysis is, as the name would suggest, analysing the code that you write. This is important because getting a computer to apply specific rules to your code will catch issues every time, while a human will catch issues some of the time, or at best, most of the time.

Looking at the properties of a project in Visual Studio allows you to enable code analysis on build, in a projects properties, that looks something like:

Code analysis defaults to being switched off. Once you turn it on, you get a selection of which rule set to apply.

So how does code analysis slow you down?

Any process takes time, so every time code analysis runs, it takes time. This is generally a very small amount of time, so tends to go unnoticed. The problems comes when you have large solutions with lots of projects and lots of code. The bigger things get, the more time code analysis takes.

Don't get me wrong, code analysis is very important for code quality, perhaps more so as your solution gets large. The question is, do you want to run code analysis every time you compile even a small part of your solution? Depending on your abilities and exactly which rule set you are applying, it may be rare that you see an issue raised by code analysis. So do we need it running on every single compile?

Lets have an example

I have a real world solution with 60 projects (in visual studio 2013), when running a complete re-build :

• with code analysis on = about 1min 30 seconds,
• code analysis off = about 30 seconds

That’s a saving of over a minute per build, if I did 30 complete re-builds a day that’s more than a 30 minute saving, PER DAY!

Now Visual Studio tends to be clever, so when you run a build it only builds projects that are changed, or impacted by changes, so most builds you do won't build everything in the solution, meaning code analysis won't run on all of the projects either.
Spending lots of time waiting for a build isn't just a waste of time, it can lead to context switching. For example, occasionally I’ll build something, I do something else while it builds(as it takes so long), by the time it’s done I’ve forgotten exactly why I started to build. I've lost focus on what I was trying to do.

So now that we've decided we don't want to run code analysis for the majority of builds, what are the options for turning it off?

Three Ways to Turn Code Analysis Off

1. Per Project

Well we could just turn it off on each project and enable it for gated check-ins, but then if we do actually want it to run on our local machine we'd have to enable it on every project, which would be a bit of a pain.

2. At a Visual Studio Command Prompt

We can go to a Visual Studio command prompt, enter:

set DevDivCodeAnalysisRunType=Disabled

then:

devenv

This will start an instance of visual studio with code analysis turned off. This is useful if you want it just for a specific Visual Studio instance.

3. An Environment Variable

My preferred option is an environment variable, create one at System level named “DevDivCodeAnalysisRunType” and set its value to “Disabled”. Any instance of Visual Studio that you start with this environment variable set will have code analysis disabled. Then if you want to enable it, change the value to something slightly different (maybe just add an extra character on the end) and start an instance of Visual Studio. I've tried this in Visual Studio 2012, 2013, 2015 and 2017 and it works in all of them.

The savings I make from not running code analysis may be slightly offset by having something fail to build on a gated check-in which does do the code analysis, but wasted time here is negligible compared to all of the saved compile (or rather analysis) time. The code analysis rules we currently use may kick up an error for me once every two or three months. If required you can switch code analysis back on and do a build before check-in, just to ensure your gated check-in isn't going to fail due to a code analysis error.

4. Command Line (ok, I said 3, consider this a bonus!)

When running builds in TFS / VSTS / Visual Studio Online, you may not always want to run code analysis, for example you might want to run it on a gated check-in, but then not for a release build further down the line. As part of a Continuous Release / Continuous Integration you want things to run quickly, so you don't want to waste time running code analysis multiple times on the same code. The command line option to stop code analysis when running MsBuild.exe (i.e. when doing builds in TFS / Visual Studio Online) is:

/p:RunCodeAnalysis=False

The down side?

Can there really be a down side to saving time? Well, I used to use long compiles as a reason to stand up, get a coffee, that sort of thing. Now that compiles are done so quickly I rarely get up from my desk. Oh dear.