More than one FxCop tip

by Matt 8. April 2007 18:02

FxCop is pretty useful. No, really. Automated code review type thing. Sort of. And here I am about to give you the best FxCop tip in the world. Well, actually the best two FxCop tips. Ok, make it three. Ah stuff it, here's a whole bunch of them.

First top tip - unless you're using the version of FxCop that's integrated into Visual Studio (I'm not), you'll want to define the CODE_ANALYSIS symbol in your project settings. This is because the SuppressMessageAttribute class is decorated with a ConditionalAttribute with the CODE_ANALYSIS symbol. In other words, the SuppressMessage attribute will be ignored unless you define CODE_ANALYSIS. (Only define it for debug projects. Consider that a bonus tip.)

(Of course, you might actually want it to be ignored to stop over-zealous/lazy programmers suppressing FxCop violations instead of fixing them. But hey, let's try and stay glass half full, eh?)

Here's one I prepared earlier - ensure your spell check language is consistent across all users. And the top up tip is to ensure that you're all on the same version (and service pack revision) of Office.

The FxCop team blog provides a way to run FxCop as part of a normal build, including a bug and workaround. But this doesn't use a project you might have set up, so you might want to give the FxCop msbuild task from the MSBuild Community Tasks Project, or just play about with the /project command line option. (This blog post has more details on FxCop/Visual Studio integration, including a link to an FxCop addin, that I'll have to have a look at.)

Speaking of projects, FxCop bizarrely saves the messages to the project file after each run. The advantage of this is that you get to see what's changed between runs, with new messages displayed in bold, but you do need to have the file checked out each time you run an analysis. If you don't want this, uncheck the option to save Active messages in the project. You still want to keep exclusions checked though - that's a change that you do want saved. Alternatively, you can save active and excluded messages to the report file and use the /import switch to FxCopCmd to get it to read those files. This way, your project file doesn't have to change at all, but managing the reports in source control could get tricky. (I feel a post analysis script coming on...)

I think that last paragraph can be summed up simpler - read the docs. Or at least, read the "Managing FxCop Projects" page. It's dead easy to get started with FxCop, but once you start to get a bit more advanced, it's not terribly obvious what's going on. And if you're putting FxCop into a build process, you'll really want to read through "Using FxCopCmd".

But the number one best FxCop tip? Simple. Run it from day one. Don't let the violations back up, or you'll never bother to clear them down.

Tags:

.net tools | FxCop

FxCop spell check language

by Matt 24. August 2006 16:02

We had discontent on the team today. Can you believe people actually dissing FxCop? Turns out they were just upset about the spelling - it's making us spell in American English, rather than British English.

I can feel the pain - it still makes me wince whenever I see "Favorites". And it's just wrong to spell it "color".

Easily fixed - simply change the spell language in the project options dialog.

Or, if you never use the GUI (e.g. if you've gone continuous integration crazy) then it's in the .fxcop file. It's a normal .net locale; "en-gb", "en-us" or just plain "en". (//FxCopProject/ProjectOptions/Spelling[@Locale])

One thing that isn't surfaced in the UI is that you can specify multiple locales to check. Simply provide a comma separated list of locales. FxCop will try to match each word against the first in the list. If it doesn't match, it moves on to the next locale. Handy.

Thanks Reflector!

Tags:

.net tools | FxCop

Rel=Me

Month List

RecentComments

Comment RSS