Modern code analysis for your Xamarin/.NET solution
Visual Studio can perform code analysis of managed code with modern .NET Compiler Platform-based (“Roslyn”) code analyzers. These code analyzers inspect your C# code for style, quality and maintainability, design, and other issues.
I’m going to walk you through the options you can use based on “Roslyn” code analyzers and the configuration which works best for me at the moment.
‘.editorconfig’ file without additional packages
Both VS and VS for Mac understand when you place ‘.editorconfig’ file inside your project or solution and use the settings inside this file to enforce consistent coding styles.
‘.editorconfig’ settings take precedence over global Visual Studio text editor settings, but you should be aware of the fact that only new lines of code are formatted according to the ‘.editorconfig’ file. I admit that it’s really great that ‘.editorconfig’ file has eventually come to the .NET world and that VS honors the settings inside it, but there’s room for improvement. The formatting of the already existing code is not changed unless you run either “Code Cleanup” or “Format Document” command. Moreover, the IDE code style rules described in this file do not apply during builds, in other words, they cannot trigger a build failure. I can say for 100% that a codebase owned by at least two developers will never look consistent from a styling perspective unless you enforce it with checks in your CI pipeline. So this is the place where the StyleCop.Analyzers package comes to the rescue for your style consistency.
StyleCop.Analyzers NuGet package with ’editorconfig’ and ‘stylecop.json’ files
StyleCop.Analyzers package provides warnings that indicate style and consistency rule violations in C# code. The warnings are organized into rule areas such as documentation, layout, naming, ordering, readability, spacing, and so forth. Each warning signifies a violation of a style or consistency rule.
The severity of individual rules may be configured using ruleset files or with ‘.editorconfig’ file, also a ‘stylecop.json’ file may be used to customize the behavior of certain rules.
With this tool at your disposal, you can easily make your build fail by changing the severity of the rules that are critical to be followed by you and your teammates.
FxCop.Analyzers NuGet package with ‘.editorconfig’ file
Microsoft recommended code quality rules and .NET API usage rules, including the most important FxCop rules, implemented as analyzers using the .NET Compiler Platform (“Roslyn”). These analyzers check your code for security, performance, and design issues, among others.
The good news is that you can trigger a build failure with this tool too.
This package uses ruleset files for its configuration, but starting with version 2.9.5 it can be configured by ‘.editorconfig’ file as well. Today ‘.editorconfig’ is the preferred way while ruleset files are treated as legacy configuration.
The predefined EditorConfig and ruleset files for the FxCopAnalyzers package are located in the subdirectories of %USERPROFILE%\.nuget\packages\microsoft.codeanalysis.fxcopanalyzers\<version>\ directory.
Combining the best of three worlds
As you might’ve noticed all of these options will bring value to your project, so it’s worth using all of them in combination.
I’m going to show you how the mentioned tools may be used in practice. I’ll use a default Xamarin.Forms project created by Visual Studio for the demo purpose.
First of all, I created an empty file with ‘.editorconfig’ name and placed it in the root folder of my solution. Then I grabbed some IDE code styling settings from this page. In order to avoid doing the same configuration for each of the projects in my solution, I created ‘CodeAnalysis.props’ file with the following content.
In this file, I reference the ‘.editorconfig’ file and also have the package references for StyleCop and FxCop Analyzers. You may have also noticed the reference to ‘stylecop.json’ file which I placed in the root folder as well. This file is needed to configure some stylecop rules.
The next step is to reference ‘CodeAnalysis.props’ file in all the projects of the solution. I did it manually by adding this <Import Project="../CodeAnalysis.props" Condition='$(Configuration)'!='Release'" /> line to all ‘*.csproj’ files. There is another option which implies that you use the special name for your file (‘Directory.Build.props’) and this file will be used for every csproj file implicitly. But I prefer to do it explicitly as you might not always want to apply the settings to all the projects in your solution.
Having these packages embedded into the projects, I copied the predefined FxCop settings to my ‘.editorconfig’ file and tried to build the solution. The build succeded but with a bunch of warnings from both StyleCop and FxCop Analyzers.
Then I changed the severity of the certain rules to “error” and tried to build it again.
And I started getting errors from the compiler! Exactly what I wanted.
Going over the sets of available rules and reviewing their severity you can quickly figure out what is important to you and enforce good code style and code quality rules on your project.
Grab the sources and try it yourself, and make sure that your production project has a properly configured CI pipeline with static code analysis.
