I was a developer on the FxCop / Managed Code Analysis Team for 3 years and I have your answer. Things have changed since my time, and I had forgotten exactly how custom dictionary handling worked and so it took me quite a bit of time to figure this out. :)
Executive Summary
The short answer is that you need to remove all references to username, usernames, UserName, and UserNames from C:\Program Files (x86)\Microsoft FxCop 1.36\CustomDictionary.xml.
Normally, I would not recommend this as it should not be required, but you have found what I believe is a bug, and this is the only workaround that I could find.
Full Story
OK, now for the long answer...
The rule has two distinct checks which work as follows:
A. Check for compound words that should be discrete
- Split identifier into tokens: e.g.
FileName --> { "file", "name" }
- Spell check each adjacent pair of tokens.
- If the spell check succeeds (e.g.
filename
is deemed to be a valid word),
then we have found a potential problem since a single word should not be expressed as
two tokens.
- However, if there is a
<Term CompoundAlternate="FileName">filename</Term>
in the <Compound>
section of the custom dictionary, then it is taken to mean that
although filename
is a word, the design guidelines (largely as a nod to consistency
with prior art in the Framework that predates the existence of the rule) insist it
should be written as FileName
, and so we must suppress the warning.
- Also, if there is a
<Term>filename</Term>
entry in the <DiscreteExceptions>
section of the custom dictionary, then it is taken to mean that although 'filename' is
a word, it might also be two words 'file' and 'name' in a different context. e.g.
Onset is a word, but asking the user to change DoSomethingOnSet
to
DoSomethingOnset
would be noise, and so we must suppress the warning.
B. Check for discrete words that should be compound:
- Taking the tokens from A.1, check each one individually against the set of compound
terms in the custom dictionary.
- If there is a match, then we must warn in keeping with the interpretation in step A.4.
Notice that your warning: Username
should be UserName
is detected in part B, which does not consult the DiscreteExceptions section, which is why you are not able to suppress the warning by modifying that section. The problem is that the default custom dictionary has an entry stating that the correct casing for username
is always UserName
. It needs to be removed or overridden somehow.
The Bug
Now, the ideal solution would be to leave the default custom dictionary alone, specify SearchFxCopDir=false
in your project file, and then merge in only the parts of the default custom dictionary that you want in the CustomDictionary.xml that is used for your project. Sadly, this does not work as FxCop 1.36 ignores the SearchFxCopDir directive and always treats it as true. I believe this is a bug, but it is also possible that this was an intentional change since the directive is not documented and has no corresponding UI. I honestly don't know...
Conclusion
Given that FxCop always uses its default custom dictionary in addition to the project custom dictionary, your only recourse is to remove the entries in question from the default custom dictionary.
If I have a chance, I will contact the current code analysis team to see if this in fact a bug, and report back here...