Have you ever looked at any of the .NET DLL code? Well if you do, it all looks like it was written by the same person (what a concept). Part of the reason is that the teams use FxCop or Analyze.
Analyze evaluates code after it has been compiled. There are hundreds of rules that are grouped into these categories:
- COM (Interoperability) – rules that detect COM Interop issues.
- Design – rules that detect potential design flaws. These coding errors typically do not affect the execution of your code.
- Globalization – rules that detect missing or incorrect usage of information related to globalization and localization.
- Maintainability – rules that detect maintenance issues.
- Naming – rules that detect incorrect casing, cross-language keyword collisions, and other issues related to the names of types, members, parameters, namespaces, and assemblies.
- Performance – rules that detect elements in your assemblies that will degrade performance.
- Portability – rules that detect portability issues.
- Reliability– rules that detect correct memory and thread usage.
- Security – rules that detect programming elements that leave your assemblies vulnerable to malicious users or code.
- Usage – rules that detect potential flaws in your assemblies that can affect code execution.
If you are reading this, stop and open the solutions you are currently working on and do the following for any of your .NET 4.8 projects.
Open each project’s properties and check Enable Code Analysis on Build.
These are the rule sets that I usually select:
- Microsoft Managed Recommended Rules: For DLL assemblies.
- Microsoft All Rules: For applications including ASP.NET and console apps.
This will ensure that analysis will be done on every build. This is very important since it is much cheaper to fix bugs when writing the code as opposed to the user or QA finding it later.
After compiling, the issues show up in the Error List window as shown below.
Clicking on each issue will take you to the code. If you need to know why the code has been flagged and how to fix it, then simply click on the code in the Code column and it will take you to the online documentation.
At many jobs I work at, setting up Analyze is the first thing I do when I am assigned to a project. Many times, the other developers turn it off after I check-in my changes to source control, stating that the build is taking too long or is “painful”.
My response is “good”! It should be painful until the issues are fixed. I’ve been on projects that the solution exceeded the maximum number of violations and other that crashed Visual Studio!
Scanning the code for issues can and should be added to your build process. Do not release the code for testing by QA until the issues have been fixed or marked to ignore (by a lead on the team).