Introspection vs Reflection
Many static analysis tools use simple source-code inspection to identify issues. However, with FxCop, Microsoft decided to leverage the inherent functionality of .NET itself as the basis for creating rules. A very useful feature of .NET is called reflection. Using reflection, you can programmatically inspect other assemblies, classes, and members. You can even invoke methods or access fields, public or private, given appropriate security settings. Reflection is done without establishing a link to the target assembly at compilation time, a practice known as late binding.
Initial versions of FxCop relied on reflection as the basis for rules. However, a newer option is available, called introspection. Similar to reflection, introspection can inspect a target assembly to discover its types, and details about those types. It can also invoke members of those types. Introspection does this in a much faster manner than reflection and supports multi-threaded operations. Furthermore, introspection does not lock the files under analysis, a problem suffered by previous versions of FxCop that needed to use reflection. Given the clear advantages of introspection over reflection, Microsoft has leveraged introspection with the rules that are shipped with Team System. We'll also use introspection in this section for our custom rule.
As theoretical is very well discussed in the below-mentioned article in the PDF, I am not reinventing the wheel again.
Using the Code
This article contains the code for the below mentioned custom rules. The code uses .NET 2.0 and FxCop V 1.35.
- Checking for explicit usage of SQL objects in your application
- Class level variable naming convention
- Method level variable naming convention
- Validating method names
- Validating the method parameters
- Validating your assembly for valid XML comments
- How to track through session variables
- Validating Web control naming convention
- Check for dead classes in your assembly
Points of Interest
One thing is weird. If you precompile the ASP.NET application and view the IL code of the ASP.NET DLL, the locals declared in the public or private methods in the code behind file will lose their identity (the names of the locals declared will be treated as local0, local1). Happy programming.
- 2nd November, 2007: Initial post