views:

232

answers:

3

I'm currently writing a tool that parses the FxCop logfile on a large codebase. My goal is to provide graphical information about the most common warnings, sorted by namespace (subsystems of the application).

See example graphic.

This can then be used to start a discussion about which FxCop rules we care about and what actions should be undertaken to remove them.

The logfile contains two types of entries. One in which the namespace can be deduced from the line itself and one that does not. See the examples below:

[Any CPU/Release] LoggerWrapper.cs(647,28): warning CS1574: XML comment on 'CompanyName.Utilities.Logging.Internal.LoggerWrapper.WarningException(System.Exception, short, long)' has cref attribute 'CompanyName.Common.Services.Logging.LoggerWrapper.Warning(string)' that could not be resolved

You can see that this warning belongs to the namespace CompanyName.Common.

[Any CPU/Release] d:\Bld\CompanyName\2010_MAIN_F\Sources\CompanyName\Utilities\Logging\Store\EventViewer\NativeHelper.cs(254,0): warning : CA1307 : Microsoft.Globalization : 'NativeHelper.GetSid(string, out IntPtr)' makes a call to 'string.IndexOf(string)' that does not explicitly provide a StringComparison. This should be replaced with a call to 'string.IndexOf(string, StringComparison)'.
[Any CPU/Release] (-1,0): warning : CA1823 : Microsoft.Performance : It appears that field 'NativeHelper.IIsApplicationPoolSettingProperty' is never used or is only ever assigned to. Use this field or remove it.
[Any CPU/Release] (-1,0): warning : CA1823 : Microsoft.Performance : It appears that field 'NativeHelper.IIsSettingProperty' is never used or is only ever assigned to. Use this field or remove it.

In this entry you cannot resolve the last two warnings to a namespace. You have to backtrack to the first line to be able to deduce that it concerns the CompanyName.Utilities namespace.

How would you handle this situation? I'm not looking for a 100% foolproof identification, but I would like to be able to resolve most warnings to a corresponding namespace.

My strategy so far: I'm considering a two-pass parser. First I will parse the lines that in which namespace information can be deduced from the same line. In the second pass, I will search for the lines that have no namespace information and will backtrack from that position to the first line that does have namespace information.

I do not have the ability to let FxCop generate XML. Team Foundation Server does create the individual FxCop files in XML for each assembly, but the file which contains the ENTIRE logfile is in the format as described above.

Any better ideas or suggestions?

Great suggestions so far! Some extra information concerning the logfile. This logfile is generated by a Team Foundation Server teambuild. I don't know if it is possible to create a XML version from it.

A: 

You can get the output in XML format, which addresses this by nesting the reports.

That, plus a dose of XSLT, can get you a nicely formatted HTML page -- which ideally ought to just look like

Collated style report for solution: 0 messages

Generated: 13/07/2009 11:23:49
Steve Gilham
+1  A: 

Run FxCop so that you get an XML report, pair it with an XSL and you got your graphical presentation. I think that there are a few XSL sheets to choose from, but I think this one does the trick.

Typically I let CruiseControl.NET do this for me, using the msbuild file of the project in question.

Fredrik Mörk
Good answer, but I only have access to the entire logfile in plain text, not XML.
Sardaukar
A: 

Good answers, but I only have access to the plain logfile in ASCII, so an XSLT will not work here.

I solved it by writing my own parser that tries to deduce a namespace from each line. If a line with a warning does not contain a namespace, it takes the last found namespace.

Works excellent.

Sardaukar