Whidbey FxCop 1.32 ignores certain methods ?

In order to restrict FxCop analysis to the most directed result set for Whidbey (v2.0 of the framework), we've created a new GeneratedCodeAttribute (that lives in system.dll) which is used by v2.0 codegen tools, such as the ASP.NET compiler.

There's also another wrinkle: the ASP.NET compiler emits quite a bit of code that doesn't map to user source. There's no point firing messages against these constructs, as they can't be fixed. So, when analyzing a binary that's marked as having been emitted by the v2.0 ASP.NET compiler, FxCop checks the PDB to see if there's source information for the method under analysis. If there isn't, we can't be user the method maps to user code, and it won't be analyzed. Constructors are currently exempt from this heuristic, as the compiler emits a constructor (not present in the PDB) that indirectly maps to user code. If you initialize a field inline, for example, you'll get a generated constructor.

What this means is that you must have valid pdbs alongside your web app binaries in order to get a complete analysis.

Michael Fanning
VSTS Team System: Code Analysis

MichaelFanning-MS at 2007-9-9 >

There is a workaround, generate a valid PDB for the asp.net binaries. Everything should work in this case, and the cost of doing so isn't prohibitive.

Will that solution not work for you?

Michael

MichaelFanning-MS at 2007-9-9 >

Can you set and hit a breakpoint in __BuildControlButton1() while debugging?

If both conditions above are true, zip up your temporary assembly and its corresponding pdb and send them to me here. MikeFan at microsoft dot com. I'll take a look. There could very well be an issue we need to look at.

Michael

MichaelFanning-MS at 2007-9-9 >

I don't think that is the problem - I made sure that I was using the Whidbey FxCop 1.32 (and I recompiled my custom rule library). However, my test was on the June 2005 CTP and not Beta 2 - I assumed that this would not make a difference.

Guy

GuySmith-Ferrier at 2007-9-9 >

Ok, so that I understand then I think you are saying that:-
(1) FxCop ignores all methods or classes which have been marked with the GeneratedCodeAttribute

(2) The presence or absence of a PDB file makes no difference to FxCop's interpretation of the GeneratedCodeAttribute

(3) There is currently no workaround

In your original explanation you said "the ASP.NET compiler emits quite a bit of code that doesn't map to user source. There's no point firing messages against these constructs, as they can't be fixed".

I this that there is an important distinction which is being overlooked here: the generated code *does* map onto source - the distinction is that the source is an .aspx file and not a .cs file. The result, however, is that I *can* change the source (i.e. the .aspx) to fix the generated code and therefore it is valid to analyze this code.

Clearly I would like to request that you lift this restriction.

Thanks.

Guy

GuySmith-Ferrier at 2007-9-9 >

Sorry to be slow here but I don't know how to resolve what you are saying.

MikeFan> FxCop does not universally ignore items marked w/GeneratedCode. FxCop does notice when a binary is marked as compiled by asp.net (via GeneratedCodeAttribute). In this case, special filtering kicks in

Are you saying that FxCop looks for both the presence of the GeneratedCodeAttribute and also some other criteria which is built into FxCop (such as the naming convention of methods which are auto-generated) ?

MikeFan> This filtering depends on the presence of valid pdbs. If FxCop detects that a method body contains executable code that is referred to in a pdb, it will analyze that method, otherwise it will not

So I remain uncertain as to why the generated assembly from the code I sent you didn't get analyzed. The generated assembly had a valid PDB in my tests.

Thanks for your patience.

Guy

GuySmith-Ferrier at 2007-9-9 >

Thanks for the clarification. One more question then:-

You said "The ASP.NET compiler will not emit PDB information for many methods that result from the higher-level markup provided in aspx files.". Does this mean that even if FxCop is modified to allow the GeneratedCodeAttribute to be ignored that it wouldn't make any difference because the PDB information is missing ?

I have 5 or 6 rules which I feel make a valid case for analyzing generated code (specifically, analyzing aspx files and their relationship with their associated resources). I would be disappointed if it will never be possible to use these rules in .NET 2.0.

Thanks.

Guy

GuySmith-Ferrier at 2007-9-9 >