FxCop 1.36 and theGlobalSuppression.cs



Hi,


We are using FxCop 1.36 and are trying to suppress a FxCop rule for a assembly. The reason is that some Customer Names are coded Uppercase being wellkown.

Noew I followed the instruction in thread
Can FxCop 1.36 Use GlobalSuppression.cs File

1. You need to add it as a code file compiled in the project for which the suppressions apply.

So in file GlobalSuppressions.cs (selfcreated)
i simply added

using System.Diagnostics.CodeAnalysis;
[assembly: SuppressMessage("Microsoft.Naming", "CA1704:IdentifiersShouldBeSpelledCorrectly", Scope = "assembly", Justification = "...")]

2. You need to define the compiler constant CODE_ANALYSIS for that project (if for some reason that wasn't done already).

In the Solution we added the GlobalSuppressions.cs file under 'sln-> properties -> build -> Conditional compiler symbols' we added 'CODE_ANALYSIS'

having done this we still get 11101 FXCop CA1704:Naming warnings.

What are we doing wrong?

__________________
Shaalini.S
Be the Best of Whatever you are...

Hi,

There are a couple of problems with this approach:

1)"assembly" is not a valid value for the Scope property. (See SuppressMessageAttribute.Scope Property (System.Diagnostics.CodeAnalysis) for the list of possible values.)


2)Although it seems reasonable to be able to exclude violations at a higher scope (e.g.: exclude all violations of a type-specific rule at the namespace level), this isn't actually possible in FxCode. Only exclusions registered against the same target as the violation target will be considered by FxCop.


You can, however, create exclusions that will work very easily using the following steps:

In the FxCop active violations list, select the violation(s) you wish to exclude.

1) Right-click your selected violation(s).

2) From the context menu, select the Copy As -> Module-level SuppressMessage.

3)Paste the suppressions into yourGlobalSuppressions.cs file.

__________________
A.Rajesh Khanna

Hi,

Although it seems reasonable to be able to exclude violations at a higher scope (e.g.: exclude all violations of a type-specific rule at the namespace level), this isn't actually possible in FxCode.

Right. This is a common point of confusion. Assembly/module suppressions are no more powerful than inline suppressions. The assembly/module suppression contains information that ties it to exactly one problem instance. The only difference is where you have to put the attribute in your code (in a separate file/at the top of the file versus inline with the offending code).

Hi,

Thank you for replying.

Our problem is that a Brandname is containing to many upper case letters in its name. Has anyone got a suggestion how to exclude certain rules without unlevering FxCop to much?

We dont really want to exclude a it alá Command="S:\...\FxCopCmd.exe; /f:$(TargetPath) /c /q /searchgac /rid:-Microsoft.Naming#CA1704 since the rule would be gone for to much code.

This must be a common problem e.g. names like XML, BBC and so would produce the same problem.

As I said before the naming rule CA1704 and CA1709 produce 11101 warnings which makes either FxCop Rule or FxCop its self near unusable. I would have believed that this basic, simple and common senario would have solution?

I would really apprechiate any ideas how to solve this.

__________________
Shaalini.S
Be the Best of Whatever you are...

Hi all,

Have you tried adding a casing exception for this scenario to a custom dictionary?

__________________
A.Rajesh Khanna

Hi arjkhanna,

add a casing exception? must confess I don't know what that is. Could you elaborate a bit and where I should put it?

__________________
Shaalini.S
Be the Best of Whatever you are...

Hi,

See the section "How can I add custom words to the FxCop dictionary? How can I add project specific dictionaries?" at FxCop FAQ for an explanation of using custom dictionaries. If you open the custom dictionary installed with FxCop (usually C:\Program Files\Microsoft FxCop 1.36\CustomDictionary.xml), you will see what sorts of dictionary terms you can create. For your scenario, either a casing exception (Dictionary\Acronyms\CasingExceptions\Acronym) or a compound alternate (Dictionary\Words\Compound\Term) might do the trick. If you're not sure exactly what to add to the custom dictionary, you'll need to provide the exact terms that are giving you CA1704 and CA1709 problems in order to anyone to be able to provide more specific help here.

__________________
A.Rajesh Khanna

Thank you rajesh,

our proposed idea conceptionaly works and id like to thank you for the info here!

After playing about with the file you mentioned it turns out that the main problem is that most of the 11000 warnings come from unmarked generated code . Mostly in chunks of 7 which would be > 1000 casing entries.

But I am glad to say I could still learn more about FxCop thanks again.

__________________
Shaalini.S
Be the Best of Whatever you are...