StyleCops.Analyzers is one of the tools that allow us to analyze the source code and check for any bugs. Previously, it was made available as a Visual Studio extension that you download and install. Now—thanks to the Roslyn compiler platform—it is also available as a NuGet package that can be downloaded. The NuGet package is the recommended approach to download and set up the build job.
StyleCops.Analyzers runs with the build job and reports any
problems with the code. Previously, our jobs succeeded and did not report any problems with the code. We will add the package for StyleCops.
Analyzers and then run the build again and study the results.
You can install the Visual Studio extension for StyleCop.11 We highly recommend and encourage you to download and install StyleCop.
Analyzers from the NuGet package manager. The benefit you get by using NuGet is that everyone gets to use code analysis without having to install anything. The NuGet package manager provides a native development experience for .NET Core developers. If there is an update for the package, you can easily upgrade your existing packages with a single command.
Finally, NuGet packages depend on your .NET Core version and not the Visual Studio version. The packages are available in environments where Visual Studio is not available, such as Linux or MacOS.
Open a terminal session inside the project folder and execute the following command to add the package:
$ dotnet add package StyleCop.Analyzers
This will add the package to your project. If you are using an IDE, you can use the NuGet package manager console or the GUI to add the packages too. From the console, you can execute the following command:
11 Extension can be found at: https://marketplace.visualstudio.com/
items?itemName=ChrisDahlberg.StyleCop. You can also explore more about the project on GitHub, at https://github.com/StyleCop/StyleCop.
Install-Package StyleCop.Analyzers
If you are working in the GUI window, you can search for StyleCop.
Analyzers and install the package that way (see Figure 2-9).
Once you install the package, your build commands will contain the output of this package too. Now, if we rerun the build command, the output will no longer be a clean result. Instead of our basic program, the output will contain elements that we did not even think of (see Figure 2-10).
Figure 2-9. NuGet package manager showing results for StyleCop.Analyzers
As you see, none of these are errors and will not break the build automatically. But they help the developers enforce policies for code standards and qualities. Several warnings say that the “elements should be documented.” This provides an easy check to verify if everything in the project has an associated comment with it. Comments in the .NET Core environment have always proven to be useful and they help developers quickly make their way through difficult code. Then there are a few other warning messages, such as “Element ‘Program’ should declare an access modifier.” This message tells us that the code is missing an access modifier in the program. Leaving these can direct the compiler to use implicit access modifiers, which can sometimes lead to unexpected code and results.
We are not required to solve these warnings and fix them. You can safely ignore them if you think you know what you are doing. There are also ways in which you can politely silent the rules12 in the package.
There is an intensive amount of documentation available on the GitHub repository that can help you get started with the installation and
configuration of this package to suit your needs.
12 StyleCop.Analyzers uses a stylecop.json file that lets you define rules for your project, based on the policies and settings that your organization follows.
Read more on this on GitHub, at https://github.com/DotNetAnalyzers/
StyleCopAnalyzers/blob/master/documentation/Configuration.md.
Figure 2-10. Warnings are shown by the code analysis in Visual Studio
Figure 2-11 shows a sample rule configuration file being edited in Visual Studio IDE.
Visual Studio provides a good autocomplete suggestion for the rule configuration. You can commit this configuration file along with the code so that everyone uses the same configuration throughout the repository.
Most of these code review features are also a part of the Visual Studio IDE, so if you are working with Visual Studio, you can get these features to build right into the IDE for you. This also changes how you control the impact of these settings and rules on your development environment. You can control the settings for this in the .editorconfig13 file to the project and apply the necessary settings and changes (see Figure 2-12).
13 The .editorconfig file is a standard for management of several settings and configurations across the IDEs and development environments. Learn more at
Figure 2-11. Code analysis configuration in JSON, showing different options to configure the rule sets for language analysis
Both are plain-text files, and you can use them in Visual Studio or non- Visual Studio environments. The difference is that Visual Studio also provides an autocomplete feature that might not be available in other IDEs. It is best to keep these files in your version control. These settings can be applied across devices and development environments on your machines. They can also help enforce a standard of development.
The problem with package-based code-analysis solutions is that they are limited in their functionality and features. Most tools are prohibitively expensive for indie developers and sometimes require an enterprise license.