The difference between command line and GUI is that I use environment variable to point FxCopCmd to right assemblies. I also load the report to compare, but I do not really see the reason...
Any idea why I am having that problem ?
Thank you for helping.
I'll take a look at this tomorrow. Source information is only populated as the direct result of an analysis. But, assuming your report XML contains this information and your violations are importing correctly, that information should be present in the GUI (unless there's a problem with this functionality, which is certainly possible).
I'll post more on this soon,
Michael
Here's what I did:
1) analyzed a binary w/pdbs using FxCopCmd.exe, generated an output report: out.xml
2) opened FxCop GUI. added the binary in question, imported the report file out.xml
Result: source locations were imported along w/violations (where relevant, not all violations will contain source file information).
Do the steps above work for you as well? If so, we need to find out what the difference is in your scenario. Can you describe it in greater detail?
Michael
[1] Create new FxCop project using FxCop GUI. I add number of assemblies to it. In addition, I disable rule "Specify IFormatProvider" from "Globalization" set of rules. Save the project "abc.FxCop" and close FxCop GUI,
[2] Open the project with Notepad and modify the path(s) to the assembiles, so they use environment variable (this allows me to perfrom "debug" and "release" analysis using the same FxCop project); example: <Target Name ="$(ProjectDir)/../src/MyApp/bin/%TARGET%/MyApp.dll" Analyze="True" AnalyzeAllChildren="True" />
[3] Run FxCopCmd with the previously created/modified project and generate standard report. Note: my %TARGET% envir. var. is set to "debug" and I use /o:abc.xml option to produce the report,
[4] Run FxCopCmd with the following options:
fxcopcmd.exe /p:abc.FxCop /s /v /i:abc.xml /o:abc.FxCop
Note: abc.FxCop will not be generated if FxCop does not find any new exceptins comapring to abc.xml - so at least one assembly in the project must be modified in the way that new exception is produced,
[5] provided abc.FxCop project was generated, run FxCop GUI with that project file (my envir. var %TARGET% is set to "debug"). When the file is loaded I can see analysis results but instead of getting link to the source code, I am getting <Location not stored in Pdb> ,
Final notes: (1)when I am running FxCopCmd, the current folder is the folder where I store my scripts and FxCop project files, so it is not FxCop folder nor my assembly bin\debug folder. Specifically, my command that launches FxCop is ..\tools\FxCop\FxCopCmd.exe
(2)I do not have "full" FxCop installation; instead I just use minimum set of FxCop binaries copied to the ..\tools\FxCop folder
(3) Although it may seem that what I am doing does not match some expected standards, I have to go that way because I try to introduce FxCop the team of developers and I am looking for best ways of making this transparent.
I hope that now you will be able to see the problem as I do and perhaps tell me what I can correct in my workflow to get the source code links.
Thank you very much.
1) are you certain that the violations you're looking at might, in fact, generate file and line information? source details are only available for method bodies.
2) when you open abc.fxcop, are pdb lookups available? select Project/Options in the GUI. Is 'Attempt source file lookup' checked? If not, you need to change your project defaults (select Tools/Settings, click the 'Project Defaults' tab, check 'Attempt source file lookup').
3) if source lookups are enabled, and you are entirely confident that a violation should have that information, does it appear if you re-analyze abc.fxcop (from within the GUI)? if it does, then you've probably found a bug in fxcop. if it does not, you need to verify there are good pdbs alongside your target binaries.
Let me know how things go for you.
Michael
1) are you certain that the violations you're looking at might, in fact, generate file and line information? (...) Yes, 100%.2) when you open abc.fxcop, are pdb lookups available? select Project/Options in the GUI. Is 'Attempt source file lookup' checked? Yes, lookups are available in the "basline" (abc.xml); the option "Attempt source file lookup" is enabled.
3) if source lookups are enabled, and you are entirely confident that a violation should have that information, does it appear if you re-analyze abc.fxcop (from within the GUI)? (...)No it does not appear when I repeat analysis with abc.fxcop however "pdb" files are identical to those used to produce the abc.xml, which includes source code information
After couple of hurs and multiple scenarios tested, here is my conclusion: FxCopCmd.exe will not produce correct information about line number if the output report is redirected to *.FxCop type of report (which is, as far as I understand, a compound project/report file). If the output report is redirected to *.xml, the source code information is generated correctly.
So, the scenario of reproducing the problem is dead simple:
[1] Using FxCop GUI create new project; make sure "Attempt source file lookup" option is enabled; save the project file
[2] Run FxCopCmd with the project file from #1 and with option /o:abc.xml - the report abc.xml will include full information about source code
[3] Run (again) FxCopCmd with the project file from #1 and with option /o:abc.FxCop - the report will not include information about source code
It looks to me like a bug in FxCopCmd.exe.
?
Thank you
The real confusion in the scenario you describe is when re-analyzing the generated project file does not result in pdb information appearing. This does not repro on my side, could you verify that result? Please do the following:
Compile the following code, csc /debug+ /target:library test.cs:
using System;
public class Test { public void HUIUHIU(){}}
Analyze this file using FxCopCmd, generate a project file:
FxCopCmd.exe /f:test.dll /o:out.fxcop
Open out.fxcop in the GUI. Click on the 'Long acronyms should be pascal-cased' violation. Note there is no file & line information. Hit F5 to re-analyze. Select the long acronym violation again. You should see file & line details.
Michael
Your example gives expected behavior. *.FxCop file does not yield source code links but second analysis from GUI brings them back.
You said: "FxCop never persists source file and line information to a project file."
- now I understand why my *.FxCop file never includes that information. Suggestion: perhaps you could consider adding a config parameter that enables storing source code info in *.FxCop files on user's demand ?
Final question: is there a way of loading *.xml report together with the project file into FxCop GUI app at startup ? This way I could load original FxCop project and *.xml report (which has source code links) instead of loading compound *.FxCop that I produce at runtime ?
Thank you very much for your great help !
Michael
I am really impressed with FxCop forum. I wish all technical newsgroups present the same level of quality.
Great thanks and all the best to FxCop team - you are doing amazing job to help developers succeed.
Thanks for the kind words! We're very serious about the FxCop community work, it's important. 8)
Michael
