So I’ve finally managed to get fxCop officially adopted on a work project (*). Better yet, thanks to an upgrade, we now are using the Ultimate Edition of Visual Studio: I no longer have to use the command line of fxCop . Instead, It’s integrated right into the build.

Of course, no improvement goes unpunished.

The way you configure fxCop changes when it’s integrated.

For example, the handling of custom dictionaries is entirely different. Instead of putting the CustomDictionary.xml file in just the right place, you add it to your project, and configure the build action to CodeAnalysisDictionary.

In fact, it’s more work than this - as I want to reuse the same dictionary file across multiple projects. Here’s what I’ve ended up with …

  1. Added my CustomDictionary.xml file as a solution item.

  2. Select “Add Existing Item …” within every project, adding the dictionary file as a link.

  3. Ensure each link is configured with BuildAction CodeAnalysisDictionary.

I wonder what I’ll have to do with the immutable types list …

(*) This is much less important than it sounds. There are issues of architecture, performance and functionality that are much more important than mere static code analysis. But, all things being equal, I’ll take any tool that helps me do a better job.

Comments

blog comments powered by Disqus
Next Post
A New Version of FxCop  17 Oct 2010
Prior Post
Where does your challenge come from?  24 Sep 2010
Related Posts
Browsers and WSL  31 Mar 2024
Factory methods and functions  05 Mar 2023
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
Archives
September 2010
2010