This is one of my babies and I’m really stoked to hear this presentation by Kathleen Dollard. Even better, this is going to be a show on FxCop, something that I’ve always wanted to use, but have never wrapped my head around how to use it properly in a project environment.

Code reviews done by humans are very difficult to reproduce. People will catch something one time and miss it the next time. We need to be able to reproduce this process consistently to guarantee that code meets the standards that we set out prior to starting development.

Dynamic looks at the state at a point in time and determines if it is correct. Dynamic analysis should be considered to check things like Fonts, Access Keystrokes, Max Form Size, etc. Consider having all new forms call one method to do this work.

Formalized analysis must evolve as the industry evolves so that it stays pertinent.

Static analysis looks at the source code base and searches out potential problems. This can be done through Source Code analysis, Reflection, walking IL and Binary Introspection.

Source Reviews will hit a wall quickly. Reflection requires that you can lock the file, that the code is running and there is a wall that will be hit when analyzing this way. Binary Introspection maps your assembly without requiring it to be loaded and you can find out all things about the code.

When working with FxCop, if you are receiving “Identifiers should be Spelled Correctly” you can change the Dictionary.xml file and add the word to the Recognize element.

FxCop v1.35 has a new dependancy on the Office Spell Checker. Build servers running FxCop as part of the build server will now require MS Word to function.

A good point that people struggle with when using FxCop is when to fix code that the developer knows is correct, but FxCop is complaining about. Don’t fix the item just to please FxCop. Instead tell FxCop to ignore the rule or change the dictionary to bring it into compliance. You can’t apply FxCop to your development environment without suppressing some messages. The rules can be suppressed either at a project level or at a specific instance of the breakage.

FxCop is a fabulous training tool if people take the time to read through the explanations of the errors or the documentation.

FxCop is a difficult tool to move to. The rules are evolving. Learn to live with the fact it’s a picky tool. It’s better that way. Writing rules is a tough thing to do. It’s difficult to create custom dictionaries.

Wow. Kathleen Dollard is a presenter that everyone needs to see once. The passion flows like water in the spring. She knows her stuff and it’s apparent that FxCop is not the limit of her knowledge scope. Like I said before….Wow. The Edmonton .Net User Group needs to look at this speaker for a possible engagement.