locked
Find suppressions that is no longer valid RRS feed

  • Question

  • I the perfect world this would not be a problem, but I have no tfound that world yet ;-).

    Has anyone found a easy way of finding suppressions in code and the project suppression files that are no longer valid? One solution is to delete them all and run code analysis for all projects, but this seems very colplicated, especially for the ones within source code. You also risk loosing justification on the valid ones.

    One could imagine that this could be made into a FxCop rule and shipped with future versions?!


    Tore Østergaard Oticon A/S
    Tuesday, January 4, 2011 8:30 AM

Answers

All replies

  •  

    I'm not sure I understand the problem, for a "no longer valid suppression file/statement", do you mean

    the warning is fixed, but we don't delete the suppression statement?

    or, the FxCop rule is disabled?


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, January 5, 2011 1:29 AM
  • Sorry, should have been more specific!

    I mean when the warning is fixed. An example I see is the CA1811:Avoid_uncalled_private_code and CA1812:Avoid_uninstantiated_internal_classes, where you actually fix the warning somewhere else, than where the warning is suppressed.


    Tore Østergaard
    Oticon A/S, Denmark
    Wednesday, January 5, 2011 7:57 AM
  •  

    From my understanding, the scenario looks like:

    1. Run FxCop code on a project, and add suppressions for some warnings.

    2. We fixed some warnings, but didn't remove corresponding suppressions.

    3. Now, we want to find out suppressions that don't take effect (or invalid) from source code, and remove those suppressions.

    am I right?

     

    As far as I know, Visual Studio Code Analysis cannot find out which suppression is invalid, so, if you have a global suppression file, you may remove the file, and re-run code analysis; if we suppress those warnings in code, we have to move those suppression manually (you can right-click the SuppressMessage attribute, and select Find All Reference to find all in-code suppressions).

     

    We add suppressions for warnings that we do not plan to fix, it is better for us to remove the suppressions as soon as a warning is fixed.


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, January 6, 2011 1:57 AM
  • I totally agree on your last comment, but unfortunately this is not the case for all software developers ;-).

    Thank you for your answer, but I will still let this question be open for people out there that might build a tool for this scenario.


    Tore Østergaard
    Oticon A/S, Denmark
    Thursday, January 6, 2011 6:56 AM
  •  

    Thank you for your understanding, by the way, you can submit your suggestions to Microsoft via Connect feedback portal http://connect.microsoft.com, Microsoft engineers will evaluate them seriously, thanks.


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, January 7, 2011 12:48 AM
    • Marked as answer by eryang Monday, January 17, 2011 6:39 AM
    Monday, January 10, 2011 2:17 PM
  • You can use the stand-alone FxCop UI application for this.  Add the "Seen Last Run" column to the "Excluded In Source" results tab.  After analysis, this column will show a false value for any in-source suppressions for which a corresponding violation was not found during the analysis run.  In order to maximize the reliability of the results, you should ensure that you are using the same set of rule assemblies for the analysis that you use when running the analysis from Visual Studio.
    Monday, January 10, 2011 2:29 PM