Any reason not to enable CODE_ANALYSIS in production builds?

Question

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

Answer 1

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.