none
I don't seem to be able to suppress a code analysis message across a whole project RRS feed

  • Question

  • I want to suppress CA1303 across an entire project (or namespace would do, or whole solution would be even better - it's a Windows Forms project which will never be localised and is littered with autogenerated blah.Text="so-n-so", I'm sure you've all been there).

    Shouldn't I just be able to put something like:

    [assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Globalization", "CA1303:Do not pass literals as localized parameters")]

    into GlobalSuppressions.cs? No matter how I set (or omit) the arguments (Scope, Target etc.) on the SuppressMessage attribute I just can't seem to get it to work.

    It's VS2012.

    Anyone know the trick?

    Thursday, July 5, 2018 8:43 AM

Answers

  • I'm afraid the behavior you're seeing is correct and it really doesn't have anything to do with globalsuppression.cs. That file is just there to allow you to put your analysis rules in one place rather than scattered across your source files.

    FxCop (and the newer Roslyn implementation) only supported suppressing a single instance of the rule (unless the rule itself applied to everything). There was talk about allowing for suppression at scopes (e.g. namespaces, etc) but that wasn't implemented. It came back around when the migration to Roslyn occurred. I believe there are a couple of rules that may support it but it wasn't widespread, I could be wrong though.

    The Roslyn migrated version is here and it doesn't appear to support scoping so short of turning off the entire rule (or at least for your assembly) then I don't know a way around it.



    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Culicoides Tuesday, July 10, 2018 8:22 AM
    Monday, July 9, 2018 2:32 PM
    Moderator

All replies

  • That should suppress it globally. Did you generate this manually or have the tool auto-generate it for you?

    EDIT: To clarify, for a solution-wide answer you'll need to either replicate this in each project or create a single suppression file and then use the add as link option to add it as a link to each of your projects.


    Michael Taylor http://www.michaeltaylorp3.net


    Thursday, July 5, 2018 2:07 PM
    Moderator
  • It was generated by the tool for one particular instance, and then I edited it manually, removing the Member Scope and Target arguments - as I said, I tried various combinations of arguments, including this one (all three removed).
    Thursday, July 5, 2018 2:41 PM
  • You can disable it in ruleset file. If your application will never been localized, it doesn't matter this rule is disabled.You cannot to suppress it in code or suppression file.

    https://msdn.microsoft.com/en-us/library/dd264949.aspx

    Thursday, July 5, 2018 4:56 PM
  • Hi Culicoides,

    Thank you for posting here.

    Please try to use the code below to do the suppress code analysis.

    using System.Diagnostics.CodeAnalysis;
    
    namespace CodeAnalysisSample
    {
        class Library
        {
            [SuppressMessage("Microsoft.Performance", "CA1303:DoNotPassLiteralsAsLocalizedParameters")]
        }
    }
    

    For more details, please refer to the MSDN document.

    https://docs.microsoft.com/en-us/visualstudio/code-quality/in-source-suppression-overview

    https://msdn.microsoft.com/en-us/library/system.diagnostics.codeanalysis.suppressmessageattribute%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396#Examples

    Best Regards,

    Wendy


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, July 6, 2018 7:18 AM
    Moderator
  • PetrB

    We use a common team-wide ruleset file for all our projects, so I cannot go changing the rules just to suit me and my project. I cannot see anything in the link you provided that indicates that this rule cannot be suppressed, and it certainly can be suppressed in code, I've done it, so I still don't understand why I can't suppress it in globalsuppressions.cs.

    • Edited by Culicoides Monday, July 9, 2018 8:36 AM
    Monday, July 9, 2018 8:24 AM
  • Hi Wendy,

    I'm not sure why you would suggest setting the category to Microsoft.Performance, when the message is quite definitely of category Microsoft.Globalization. Nevertheless I tried this in my GlobalSuppressions.cs file - but it didn't work. So I am still in the dark. (Thanks for the other links, but they are to the Microsoft documentation and I have already studied this at length)

    Monday, July 9, 2018 8:35 AM
  • To all listeners:

    I have also tried adding this:

    [assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Performance", "CA1820:TestForEmptyStringsUsingStringLength")]

    to the GlobalSuppressions.ce (it's legacy code and there are a lot of instances of this) but it doesn't work either.

    Is there a set of suppressions that simply don't work in GlobalSuppressions.cs?? Or am I doing something wrong?

    Monday, July 9, 2018 9:27 AM
  • I'm afraid the behavior you're seeing is correct and it really doesn't have anything to do with globalsuppression.cs. That file is just there to allow you to put your analysis rules in one place rather than scattered across your source files.

    FxCop (and the newer Roslyn implementation) only supported suppressing a single instance of the rule (unless the rule itself applied to everything). There was talk about allowing for suppression at scopes (e.g. namespaces, etc) but that wasn't implemented. It came back around when the migration to Roslyn occurred. I believe there are a couple of rules that may support it but it wasn't widespread, I could be wrong though.

    The Roslyn migrated version is here and it doesn't appear to support scoping so short of turning off the entire rule (or at least for your assembly) then I don't know a way around it.



    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Culicoides Tuesday, July 10, 2018 8:22 AM
    Monday, July 9, 2018 2:32 PM
    Moderator
  • Thanks CoolDadTx - I guess I'll just have to accept that it can't be done. However, it does raise the question, why does GlobalSuppressions.cs contain this comment:

    // Project-level suppressions either have no target or are given
    // a specific target and scoped to a namespace, type, member, etc.

    It does rather imply that there is such a thing as a "project-level suppression" - and if that doesn't mean a suppression that acts on the whole project then it's very misleading, and I wonder what it does actually mean.

    Monday, July 9, 2018 3:12 PM
  • My understanding of this comment is simply that the file contents are for the entire project rather than a single code file. Within this project-level file each rule either has no targets (which does make it apply to the entire project) or the rule must explicitly scope itself to identify which member (because you're not using a suppression on the item itself). But that is just my understanding.

    Michael Taylor http://www.michaeltaylorp3.net

    Monday, July 9, 2018 3:18 PM
    Moderator
  • I'm sorry if I'm being stupid here, but you say "... each rule either has no targets (which does make it apply to the entire project)...", which surely means that a suppression which has no target specified (as mine are) should apply to the whole project.
    Monday, July 9, 2018 3:49 PM
  • Sorry, let me clarify by what I meant. When a rule is defined (by the person writing the rule, not your suppression of it) then they have to decide what target(s) the rule applies to, if any. Some rules are assembly level (e.g. an assembly must be signed) and therefore don't require a target while other rules are far more specific (e.g. a class containing disposable fields should implement IDisposable). Rules that can appear multiple times in a single project also fall into this category.

    For these types of rules the target is required so the analyzer knows which instance(s) to suppress the warning from. CA1303 is one of these rules. I may suppress it for a call to my logger function, but not MessageBox for example. Hence the need for a target. Targets aren't optional unless a rule decides that they can be. I'm not aware of any and it would appear CA1303 doesn't implement it as such either.


    Michael Taylor http://www.michaeltaylorp3.net

    Monday, July 9, 2018 4:34 PM
    Moderator
  • I would recommend that if you would like to see this feature then go over to the Roslyn analyzers (I provided the link earlier) and put a GitHub issue in to request the feature. I see it as useful myself or at least an assembly-level rule that says to ignore globalization. However I believe the response for an assembly level rule would be to simply ignore it. Having said that I think you'll find the newer code analyzers may work out better so perhaps you may be better suited at trying to upgrade to VS 2015+ so you can take advantage of these changes if they do implement them.

    Michael Taylor http://www.michaeltaylorp3.net

    Monday, July 9, 2018 4:37 PM
    Moderator
  • Thanks Michael, for taking the time to write a really comprehensive answer. I may not have solved my problem, but I've certainly learnt something.
    Tuesday, July 10, 2018 8:21 AM