How do you find issues in your code? Many of these rules have been ingrained in my brain for the over 20 years I have been using .NET, but I still need to use tools to speed up this process or to find the ones I miss. Using a toollike Analyze in Visual Studio will dramatically decrease the time it takes to find issues, so you can get back to adding features so you can obtain more customers!
I am recommending these tools since they are the ones that I have used for many years and are part of
my workflow before I commit.
This information will appear in a new chapter in the 7
th edition of my
Rock Your Code: Coding Standards for Microsoft .NET book that will be released in early 2021. You can pre-order an autographed copy by
clicking here.
Visual Studio Analyze
Analyze has been available in most of the Visual Studio editions for a long time and used to be based on FXCop. Originally, FXCop was an internal Microsoft tool for the .NET team to analyze code. Much of the first edition of my coding standards book was taken from FXCop before it was released publicly. Analyzing .NET 5 code has dramatically changed, and I will walk you through it.
In .NET 5, instead of using FXCop, code style analysis is configured using a new file type called .editorConfig. EditorConfighelps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable, and they work nicely with version control systems.
Reading how all this works on the Microsoft Docs site is not easy to understand and is very time-consuming. I will try to break it down into the most important things that every team should implement.
Step 1 - Analyze Setup
If you are reading this, stop and open all the solutions you are currently working on and do the following for any of your projects. Go to the project properties and click on Code Analysis.
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.
Make sure to check “Enforce CodeStyle on build” (not default). More details about this later.
Step 2 - Install EditorConfig Language Service Extension
Before we discuss the .editorConfigfile used in code analysis, first install the
EditorConfig extension created by Mads Kristensen, Senior Program Manager at Microsoft. This extension will make it much easier to configure the .editorConfig file.
Currently, this extension does not recognize all settings available for .editorConfig.
Step 3 - Create .editorConfig File
To create the .editorConfig file, right-click on the project, select Add, then .editorconfig File. The default setup only includes two minor rules.
To add the missing rules, open the .editorConfig file, and click on the light bulb. Then select Add Missing Rules, then All. Unfortunately, this extension does not add all available rules. I have
reported this to the extension author.
If you would like to see how my .editorConfig is set up, you can go to
here.
Step 4 - Running Code Analysis
There are two ways to run code analysis in Visual Studio.
Running During Build
In step 1, I showed that you should have Run on Build enabled. This is a must because dealing with issues while you are coding is far easier to fix and much, much cheaper.
Now every time you build the project or solution, code analysis will fire off after the build and then 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.
Tip
To make sure all assemblies are analyzed, make sure to build using Rebuild Solution.
Running Using Analyze
The second way you can run code analysis (this is the way I use the most) is to manually run Analyze. Just go to Analyze on the top menu bar and then click on Run Code Analysis, then choose On Solution. This will build the solution and then run an analysis on the entire solution. The issues will show up the same way as in the previous method.
.editorConfig File
EditorConfig files use an INI format that is compatible with the format used by Python ConfigParser Library, but [ and ] are allowed in the section names. The section names are filepath globs (case sensitive), like the format accepted by gitignore. Here is an example of some common settings.
csharp_style_var_for_built_in_types = true : warning
This setting is for C# and creates a warning if varisn’t used for built-in types. There are none, silent, suggestion, warning, and error.
The example below is are the settings to properly name interfaces.
dotnet_naming_rule.interface_should_be_begins_with_i.severity = error
dotnet_naming_rule.interface_should_be_begins_with_i.symbols = interface
dotnet_naming_rule.interface_should_be_begins_with_i.style=begins_with_i
What are all the available settings that work in Visual Studio? Sadly, there isn’t a single source for them. I have spent
a lot of time searching the Microsoft Docs site and blog posts to find them all. If you would like to see the ones I have been able to find, I have put them in the .editorConfig file that you can view
here.
Check back often to see if I have added new ones. Also, if there are any missing, please send me an email to let me know. I will add it to the file.
Pain Is Good
At every job 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 have been on projects that the solution exceeded the maximum number of violations and others that crashed Visual Studio!
Build Process
Scanning the code for issues can and should be added to your build process on the build server or for continuous integration. 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).
Summary
I hope this will help you setup code analysis for .NET 5. I will continue to write about this on C# Corner. To pre-order an autographed copy of the new edition of my coding standards book,
click here.