Content of FxCop report file
I try to set up command line FxCop environment which uses my base report and then if new exceptions are detected it calls FxCop GUI. To get a report that can be opened by FxCop GUI, I specify /o:report.FxCop as an output file for my FxCopCmd.exe.
First thing that I do not understand is that "report.FxCop" is always smaller than if I specify "/o:report.xml" for instance. What is the reason of that ?
Second, and more important to me, is that when I open "report.FxCop" in GUI, all messages that were supposed to be "new" are not being shown as "new" (there is "No" in column "New").
Could you advise on this ?
Thank you.
[634 byte] By [
MrekM] at [2008-2-13]
The contents of the project file are intended to be compact, mergeable (that is, easily merged when edited simulataneously by multiple developers), and proprietary (meaning that tools and reports shouldn't generally be built off the content since it's subject to change).
The contents of a report are intended to be richer, stable, and not checked into source control.
So, when a violation is persisted to the project, it contains less information than when written to the output report, eg, here's some information from a project violation:
<Type Name="AllItems">
We've persisted only the info required to identify the unique target for the violation. We don't persist any metadata details re: the type itself because we will have access to the actual type metadata at load time (this actually might change in the future). Here's the corresponding entry from the report xml, note the add'l information about the type, including its kind and visibility:
<Type Name="ClassOutsideOfNamespace" Kind="Class" Accessibility="Public" ExternallyVisible="True">
The problem you've noted w/new violations not showing up as new is related to a change we made to permit project files to be automatically merged in a source control system. To do this, we were required to stop writing out information re: the last time analysis occurred. This data always changed and would therefore always cause a collision om auto-merging that required a human being to resolve. We need to contrive a new mechanism for flagging items as new. This fix is on the list for the next FxCop update.
Michael Fanning
VSTS Development: Code Analysis