views:

69

answers:

2

I am trying to get FxCop to work in a way that it analyses only the incremental changes in the exe/dll that it analyses and not the entire thing as it has anlaysed that part already.... any thoughts how one could achieve this?? ... thanks in advance...

Regards,

ASV...

A: 

I think it would be too much hassle to get this to happen. My advice would be to pick the fx cop rules that you can live with, and get all the errors/warnings out of your code. That way if another team member changes something, you will spot it, unless they are writing code that passes. in which case there is no problem.

Unless you are working on some masive project that takes ages to check with fxcop, I think this should be ok and there is no reason to only check incremental changes.

If you are in a situation where a project has got so big that it takes ages to analyse, consider refactoring. In a Visual Studio context, wherever you have folders in a project, consider making them into new projects. This will help with separation in your code, and make it possible to analyse parts of the whole solution, rather than the whole solution and all it's projects, most of which will have no changes.

Refactoring will often be quicker, with less of a learning curve, than making a really customised testing setup to compensate for a difficult scenario.

Mark Dickinson
Yeah... massive projects is something that i cant ignore and we in a process of ironing out processes... so need to be consistent, solution-wise, for all the scenarios... any thoughts?? ... can we use VS extensibility in any way??
ASV
I thought of some thing like enabling incremental builds on the Visual Studio project and then FxCop running in the post-build process would take care of the rest.... is this right to think so... would incremental builds make FxCop also look for the incremental changes in the exe/dll .. although I myself doubt this to happen so...
ASV
You should consider making smaller fxcop projects that run over different parts of the solution, rather than one big analysis. Some projects will face more change than others. If you are running fx cop as part of a continuous integration build, consider having different builds with the heavier fxcop projects running less frequently.
Mark Dickinson
I don't tink incremetal build will help. FxCop will still analyse the whole assembly.
Mark Dickinson
Thank you Mark.. but how can we have multiple FxCop projs for the same exe/dll?? .. I am using v1.36 and cant find a way to do such a thing.. could you elaborate please on the concept of creating multiple FxCop projects for the same exe/dll??
ASV
You need to break up your exe/dll if has got so big that fxcop is struggling for performance. This will be the best way going forward, there must be areas of the assembly that can be moved out into a new dll, allowing you to analyse them separately.
Mark Dickinson
Thank you Mark :-)
ASV
A: 

This is similar to this question.

Diff fxcop results

It is possible, but the results will not be 100% accurate. In an nutshell, you run the analysis on your assembly and produce a report. After the assembly changes, run the analysis again, set the FXCop project to report only new errors and import the old report as the baseline. It is best to do this with the fxcopcmd.exe rather than the UI.

The reason the results will not be 100% accurate is that it is not a trivial task to match the old report to the new code. Lines shift, code is refactored, violations get fixed, new violations are introduced, etc. So, you may get some violations reported again in the changed assemblies, even though they were reported before. But overall, fxcop does a pretty decent job creating a diff report.