Have you ever considered using a code analyzer in your .net core code? In this article I’m going to show you how to do it as simple as it may seem, only three steps. It was so hard to me to find any source about how to implement it, specially when we have multiple projects and want to disable, for example, a rule in a single place, not too many files. The first time I tried. That’s why I’ve decided to write this post. So let’s begin.
1 – Add Package Reference
Add package reference to StyleCop.Analyzers from Nuget for each project you want to analyze. If you are working with a solution file I strongly suggest that you do it by right-clicking on solution and then “Manage NuGet packages for Solution”. This way it’s easier to make sure you are using the same version for all project.
At this point, the code analyzer should be already working. However, if we want to manage rule we need steps 2 and 3.
2 – Tell to projects where the “Rules file” is
Edit the .csproj file and add the following code to set the location of the file responsible for disable, generate warning or error for the rules:
<CodeAnalysisRuleSet>../CustomCodeAnalysisRules.ruleset</CodeAnalysisRuleSet>
This tag must be placed inside PropertyGroup tag. So you would have something like this:
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<CodeAnalysisRuleSet>../CustomCodeAnalysisRules.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
Notice that I’ve set a “../” before the file name because we want to have a single for that works for all project. So this file is located at the same folder of the solution file (.sln)
3 – Manage the rules as you will
The content of the CustomCodeAnalysisRules.ruleset file:
<RuleSet Name="StyleCop rules for Core Application" Description="Custom Rules" ToolsVersion="10.0">
<Rules AnalyzerId="StyleCop.Analyzers" RuleNamespace="StyleCop.CSharp.ReadabilityRules">
<Rule Id="SA1107" Action="Error" />
</Rules>
</RuleSet>
In this example I am setting Action of the rule SA1107 to Error. That means if the rule is broken the build will fail. You could also want to disable a rule so that you won’t be noticed, for example:
<Rule Id="SA1107" Action=“None" />
Additionally, you can keep the rule but only get a warning instead of getting a compilation error.
<Rule Id="SA1107" Action=“Warning" />
Conclusion
I personally found it very useful, specially if you have an application that many people is change the code and you want to keep it following a code style.
Although some could say that this practice is too hard I believe it gives you a significant increase in maintainability level, and consequently less time for new developers to understand the code.
One last thing I’d like to mention is the fact that microsoft doesn’t follow the same guideline that StyleCop is set by default, so you might want to disable some rules such as SA1200.
StyleCop Analyser: https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/documentation/SA1200.md
Dotnet core coding guidelines: https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/coding-style.md
Denis Capeto 