I have a class like this one:
[System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Naming", "CA1709:IdentifiersShouldBeCasedCorrectly", MessageId = "Io")]
public void ParaQueFalleCalidadCodigoUnoIo_ReglaCA1709()
{
}
public void ParaQueFalleCalidadCodigoDosIo_ReglaCA1709()
{
}
I use a custom Ruleset file CustomRules.ruleset
<RuleSet Name="RulesNet" ToolsVersion="10.0">
<RuleHintPaths>
<Path>C:\Fxcop10.0\Rules</Path>
</RuleHintPaths>
<Rules AnalyzerId="Microsoft.Analyzers.ManagedCodeAnalysis" RuleNamespace="Microsoft.Rules.Managed">
<Rule Id="CA1709" Action="Warning" />
</Rules>
</RuleSet>
When I run VS2010 built in Code Analysis tool, I get this warning:
CA1709 : Microsoft.Naming : Correct the casing of 'Io' in member name '_Default.ParaQueFalleCalidadCodigoDosIo_ReglaCA1709()' by changing it to 'IO'.
Now, I can use this same rule set file CustomRules.ruleset in FxCopCmd.exe:
FxCopCmd.exe /gac /d:"C:\CompanyFramework\4.0.0.0" /f:"D:\TFS\Tests\WebApplication1\bin\WebApplication1.dll" /o:"resultsFxCop.xml" /ruleset:"=CustomRules.ruleset" /v
I get 2 errors (FixCategory Breaking, and Level Error)
CA1709 - Correct the casing of 'Io' in member name '_Default.ParaQueFalleCalidadCodigoUnoIo_ReglaCA1709()' by changing it to 'IO'.
CA1709 - Correct the casing of 'Io' in member name '_Default.ParaQueFalleCalidadCodigoDosIo_ReglaCA1709()' by changing it to 'IO'.
<Message Id="Io" TypeName="IdentifiersShouldBeCasedCorrectly" Category="Microsoft.Naming" CheckId="CA1709" Status="Active" Created="2013-02-05 10:24:01Z" FixCategory="Breaking">
<Issue Name="Member" Certainty="85" Level="Error" Path="D:\TFS\Tests\WebApplication1" File="Default.aspx.cs" Line="21">Correct the casing of 'Io' in member name '_Default.ParaQueFalleCalidadCodigoUnoIo_ReglaCA1709()' by changing it to 'IO'.</Issue>
</Message>
<Message Id="Io" TypeName="IdentifiersShouldBeCasedCorrectly" Category="Microsoft.Naming" CheckId="CA1709" Status="Active" Created="2013-02-05 10:24:01Z" FixCategory="Breaking">
<Issue Name="Member" Certainty="85" Level="Error" Path="D:\TFS\Tests\WebApplication1" File="Default.aspx.cs" Line="26">Correct the casing of 'Io' in member name '_Default.ParaQueFalleCalidadCodigoDosIo_ReglaCA1709()' by changing it to 'IO'.</Issue>
</Message>
In resultsFxcop.xml, I have seen CA1709: IdentifiersShouldBeCasedCorrectly rule:
<Rule TypeName="IdentifiersShouldBeCasedCorrectly" Category="Microsoft.Naming" CheckId="CA1709">
<Name>Identifiers should be cased correctly</Name>
<Description>Type, namespace, and... OMITED.</Description>
<Resolution Name="Member">Correct the casing of '{0}' in member name {1} by changing it to '{2}'.</Resolution>
<Owner />
<Url>http://msdn.microsoft.com/library/ms182240(VS.100).aspx</Url>
<Email>[none]</Email>
<MessageLevel Certainty="85">Error</MessageLevel>
<File Name="namingrules.dll" Version="10.0.0.0" />
</Rule>
MessageLevel for CA1709 rule:
<MessageLevel Certainty="85">Error</MessageLevel>
Two issues:
- I get Errors but CA1709 rule Action is Warning
- SuppressMessage is ignored using FxCopcmd.exe
Now, I modify CustomRules.ruleset and I execute FxCopcmd.exe again
<Rule Id="CA1709" Action="None" />
I get NO errors.
I modify CustomRules.ruleset and I execute FxCopcmd.exe again
<Rule Id="CA1709" Action="Ignore" />
I get the same 2 errors.
I need use FxCopCmd.exe and a custom ruleset.
- Does SuppressMessage works for FxCopcmd.exe?
- Why do I get errors if Action is Warning, using Fxcopcmd.exe?
- What does MessageLevel Error for CA1709 rule mean? More priority than Rule Action "Warning"?
Any suggestions?
Update
http://social.msdn.microsoft.com/Forums/en/vstscode/thread/3f8931da-9a4d-47a6-b331-8b6b07aea8d6
http://social.msdn.microsoft.com/forums/en-US/vstscode/thread/3cb6c50c-7095-4551-a4e3-a3cbc7cb85be
For the default FxCop rules, there is no easy way to modify the message level,
MessageLevel is the importance of the message, e.g. if you had thousands of messages, it probably would be a good idea to start addressing the Critical (the exclamation mark) Errors first.
Certainty is the number the Rule writer assigns to each rule, it is the likelihood that a message leads to a code change. This number is built up based on feedback from domain experts & customers and how well the heuristic used in the rule is able to avoid false positives.
Fix Category: This indicates if the fix for a violation would be a binary breaking change if the code has previously shipped. e.g you have a library with a misspelling in it that you have already shipped to customers. You now start running FxCop on it and see the misspelling. FxCop will tell you this is a breaking change. If you fix the misspelling and ship a new version of your library to customers, they can't use the library without changing and recompiling their code. So you probably want to ignore the FxCop violation on this API. On the other hand, if you never shipped, it would be totally fine to fix the FxCop violation.