Bizzare behaviour with Visual Studio Code Analysis Rule 1804

2
votes

We are using Visual Studio Code Analysis Rules for code quality checks. We have created our custom .ruleset file and marked some violations as Errors, so that every time anyone's violating these rules, he will get a compile error and have to fix the issue.

Now everything run fine with debug mode, but when I build my project in release mode, I am not getting any error with rule 1804 i.e. Remove unused locals. In fact this violation is totally absent from violation list, not even as warning!!

Knowing that one need to have build configuration set to run your code analysis rules, I have enabled code analysis for all configurations in project properties, like this - **enter image description here** Doing this works good for all other rules but 1804.

Is it seems like a bug with code analysis, or it's a valid behavior for some reason I am not aware of, and is there's anything to get it work?

I am using Visual Studio 2013

1
visual-studiocode-analysisfxcop
The warning has no teeth, basic reason it isn't turned on by default. The compiler already removes unused local variables in an optimized release build. Also note the requirement that you must have a full .pdb, another issue in a release build. - Hans Passant
Thanks @HansPassant. It was really good to know the way compiler works with unused variables. But I think it is still good to turn on this warning as we've seen instances like when a collection is being populated after heave db call or like this, and it's not being used, so not just that variable but calls to say db etc. can also be cleaned from code. Thanks - Yogi

1 Answers

2
votes

This is not as strange as you may think. FxCop acts on the binaries, not on the sources. And in Release Mode the compiler will apply optimizations, such as removing unused locals, simplifying if/else statements and other things which lead to the same execution, but with higher performance or lower memory usage.

After these pieces of code have been optimized away, FxCop won't be able to detect it.

This is why it makes most sense do to binary analysis on the non-optimized binaries.

With Visual Studio 2015, most of the analysis has been moved into Roslyn Analyzers, which will catch these issues by analyzing the source code, instead of the binary output. This will allow Code Analysis (in 2015) to detect these issues, even if they didn't make it into the final binaries.