StyleCop for .Net 5 Projects: Installation

When you work in a team it is of great importance that you all follow the same rules. Otherwise your turn a code base in a mess in no time. We settled for StyleCop because it allowed us to delegate the nitpicking of code formatting and code style to a tool that does it automatically at development time. That allows us to use the time in code reviews for the important parts.

.Net 5 is probably the version where many companies switch from the “traditional” full framework to the successor of .Net Core. As with many other libraries/frameworks, StyleCop has some tiny differences between .Net 5 and .Net 4.8 that makes it a good time to take a closer look at StyleCop and go through the whole story from installation to configuration and end with the clean-up.

This is part one of my small series of StyleCop for .Net 5 Projects:

• Part 1: StyleCop for .Net 5 Projects: Installation
• Part 2: StyleCop for .Net 5 Projects: Custom Configuration
• Part 3: StyleCop for .Net 5 Projects: Clean-up

 

StyleCop or StyleCop.Analyzers?

There was a Project called StyleCop that is no longer in active development. We use the Roslyn-based StyleCop.Analiyzers, that is its successor and uses the same ideas and concepts. Since only the implementation and nothing else changed, I keep using the old name StyleCop for everything that is not the package itself.

 

Why StyleCop?

StyleCop is around for a long time and proved its usefulness in many of my projects. It checks your code against a pre-defined set of rules and warns you if your code does not comply. Not all pre-defined rules are useful, but most are a great help. If you find rules that do not add value, you can exclude them from your configuration (opt-out) and only check what is important for your team.

The benefit of automated checking is that everyone follows the same rules, without any additional manual effort to ensure your code is compliant. If a tool checks the rules it does not matter if it is morning or evening, the same code gives you the same list of things to improve every time you check.

At first many of the checks may seem pedantic, then after all it is just a _ in front of a variable name or the lack of spaces here and there. However, those small differences grow over time and before you know it you have a lot of mental work to do just to figure out what is going on. As if that is not bad enough, you have the same discussions over code style all the time, most likely at times where other much more important things should be talked about.

In the projects I was involved over the last 12 years we figured out again and again that an automatic check of code style and formatting put an end to those and many other useless discussions. I do not know what exactly of StyleCop made such a big difference, but as long as it works, I am happy to use it.

 

Installation

We need to install the package StyleCop.Analyzers to all our projects. The simplest way to do that is to go to the Solution Explorer, right click on your solution and select “Manage NuGet Packages for Solution“:

There you can install the package StyleCop.Analyzers to all your projects in the solution:

This is a lot faster than to open one project after the other and install the package in each.

 

Create the configuration folder

StyleCop.Analyzers needs some configuration files. To keep them together I like to create a folder named StyleCopConfig next to the *.sln file:

This folder is optional. If you decide not to create one, you need to change the paths to the configuration files later on in this post.

 

Get the Configuration files

In your StyleCopConfig folder you need to put these 2 configuration files:

1. stylecop.json is used to for formatting rules and lets you finetune certain rules. You can find a basic configuration file at the StyleCop.Analyzers GitHub repo.
2. StyleCop.ruleset allows you to enable and disable specific rules. You can copy the example code from Microsoft and put it in the StyleCop.ruleset file.

Download the two files (or copy the content to the specific file) so that your configuration folder looks like this:

Sometimes the NuGet package creates a stylecop.json in my projects, sometimes it does not. Should you find stylecop.json files in your solution you can move one of them to the StyleCopConfig folder and delete the other ones.

 

Update your .gitignore file

The .gitignore file for Visual Studio prevents Git from tracking files that match StyleCop. You can look at your .gitignore file and search for a line like this:

You can delete this line or add a ! in front (that will invert the meaning of the line and in this case include your StyleCop files). If you run git status you now should see your StyleCop configuration files.

 

Reference the configuration files in your projects

Having the configuration files in your repository is not enough for StyleCop to find them. You need to modify the *.csproject file of every project and include this snipped with paths to your configuration files:

I put them before the ItemGroup with the package references, but you can place them where you like. The first ItemGroup creates a link to the stylecop.json file while the second one configures the CodeAnalyzers.

If you now compile your project you should get a rather large number of warnings. That is expected and shows that everything works.

 

Next

We did the first important steps to use StyleCop. Next week we look at how we can configure StyleCop to our needs.