Today my colleague Rob pointed out to me that enabling Code Analysis (aka FxCop) on our solution was slowing down the build time on his machine to a rather unacceptable level. After some very unscientific perf testing, watch in hand, we saw the build time increase by more than 20 seconds with code analysis turned on. Rob therefore asked me whether there was a way we could bypass it – apart from disabling code analysis altogether which is not something we were willing to consider. The only thing I could suggest was to run the solution build out-of-proc using an ‘old’ trick I’ve applied for quite a while to VS2008, courtesy of Scott Hanselman’s Parallel MSBuilds from within the Visual Studio IDE. As we have moved over to VS2010, here is how I adapted it on my machine.
-
-
Click on
-
Fill in the following details:
- Title: Parallel Build
- Command: C:\Windows\Microsoft.NET\Framework\v4.0.30128\MSBuild.exe
- Arguments: /m $(SolutionFileName) /v:m /t:Rebuild /p:Configuration=Debug
- Initial directory: $(SolutionDir)
The arguments break down is as follows:
| /m |
Switch that allows projects to be built in parallel. |
| /v:m |
Specifies the verbosity level for logging - q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. |
| /t:Rebuild |
Forces a solution cleanup and then a full rebuild. |
| /p:Configuration=Debug |
Sets the solution configuration to build for. |
Moments later, Rob came back with an answer to our original problem with Code Analysis. As it happens, all that is required is an extra property at the end of the arguments list as shown below:
/m $(SolutionFileName) /v:m /t:Rebuild
/p:Configuration=Debug /p:RunCodeAnalysis=False
After that all we had to do was to bind the new external command to a keyboard shortcut to give us the flexibility of a faster build and hopefully save us a lot of compile time in the long run.