Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Any reason not to enable CODE_ANALYSIS in production builds?

Are there any performance costs when static code analysis is enabled in a production (release) build?

Our CI server runs code analysis on a debug build of our C# projects, whereas the release build has static code analysis disabled (i.e. CODE_ANALYSIS not defined). If there's no reason to disable code analysis on production builds, then I'm wasting time with the debug build.

Reflector shows me that SuppressMessage attributes are excluded if code analysis is disabled, but I don't expect the extra attribute to affect run-time performance. Is that the only effect of enabling static code analysis (in Visual Studio 2013)?

like image 428
Joel V. Earnest-DeYoung Avatar asked Mar 05 '14 13:03

Joel V. Earnest-DeYoung


People also ask

Why is code analysis important?

By using static code analysis, you can help developers find errors before they compile or run the code and alert them about any other issues, such as a lack of inline documentation, bad coding standards, security issues, performance issues, and so on.

What is the benefit of static code analysis?

Static code analysis advantages:It allows a quicker turn around for fixes. It is relatively fast if automated tools are used. Automated tools can scan the entire code base. Automated tools can provide mitigation recommendations, reducing the research time.

What is meant by static code analysis?

Static code analysis is a method of analyzing and evaluating search code without executing a program. Static code analysis is part of what is called "white box testing" because, unlike in black box testing, the source code is available to the testers.


1 Answers

There are actual differences when compiling with the CODE_ANALYSIS keyword enabled, for example, the compiler will remove all [SuppressMessage] attributes from the assembly when it is not enabled (and may thus cause messages to show up when you run FxCop later from the command line, since the Suppressions have been removed). If you're installing your binaries on a internal system, it may be fine to leave the suppressions in the binaries. Some companies want them removed from assemblies released to 3rd parties, since the presence of these attributes (and the contents of the Justification properties) might disclose sensitive information.

When running Code Analysis on a DEBUG build you might get stricter results, certain optimizations that occur in most RELEASE builds can cause specific FxCop rules to get lost. The optimization may remove private methods (through inlining) or replace calls to constants with the value, instead of the definition of the constant. It will not be possible for FxCop to validate these items, since they have been removed. This is to be expected.

For best results: Run Code Analysis in a Debug build. For least information disclosure, remove the CODE_ANALYSIS constant from Release builds.

like image 106
jessehouwing Avatar answered Oct 11 '22 16:10

jessehouwing