I've had to hunt down Practices Checker for .NET Framework 1.1 a few times, so now I'm posting it.  It was an R&D project to help automate the search and discovery of potential coding practices and configuration settings that do not adhere to the ASP.Net 1.1 Performance checklist. 

It may seem a bit after the fact, given it is .NET 1.1, but there were a few reasons for this:  1)  our focus was more on testing how to codify our library of practices rather than a specific version;  2) we figured adding rules/versions would be easy once we understood the feasibility and work required; 3) our field was still performing code reviews for customers using .NET 1.1 so we could immediately test the impact.

Key Links

• Practices Checker for .NET Framework 1.1  on GotDotNet (download)
• Practices Checker for .NET Framework 1.1 on Channel9 (information)
• Rules checked by Practices Checker for .NET Framework 1.1

What You Need to Know

• It was an R&D project to explore and test options for tooling support around patterns & practices guidelines.
• Whereas Code analysis is focused on .NET Design Guidelines, Practices Checker is focused on patterns & practices guidelines.
• The tool was designed for helping manual inspections and audit scenarios.  It was not designed for real-time analysis or during builds/check-ins.
• It supplements manual inspection by helping you identify potential places in the code that require further analysis.
• The user interface is a bit rough and the reports need work.

Key Take Aways
The take aways for me in this project were:

• It's tough to see a bird's eye view across various "rules" libraries (Managed Code Analysis Warnings, patterns & practices guidelines, ... etc.).
• It's important to know the types of rules your tool does or does not cover (policies, requirements, vulnerabilities, and best practices).
• It's important to know your various tool options and usage scenarios (e.g. Managed code analysis plugs into check-in policies or part of a build process, custom validators would check deployment at design time, Microsoft Best Practices Analyzer would check deployment at deployment time, Practices Checker would be a manual inspection scenario ... etc.).
• It's important to know the ecosystem around your "rules" library (e.g. how do you keep your "rules" library up to date).

I'm continuing to explore various options to manage a library of building codes/practices/rules and then map out which tools can check these items, and where in the life cycle they should be checked.  I've been informally referring to this problem as "policy verification through the life cycle."