When Microsoft released the Dynamics 365 Portals source code, one of the additions they’d made to the codebase was to use StyleCop, a tool to assist in automatically analyzing C# code for the adherence of coding style rules. StyleCop rules are run during build of a project, and rule violations are reported in the Visual Studio output and error list windows based on configurable settings, such as being reported as compilation errors, warnings, or simply informational. With a set of rules in place, a codebase can be kept to a consistent coding style standard by encouraging or forcing them to be followed.
It became apparent that StyleCop wasn’t running consistently for developers after an issue was opened to report a StyleCop rule violation. It may have been a simple configuration issue on my part, but after several failed attempts at trying to setup several Visual Studio installations to run StyleCop, I decided it would be easier and better to switch the codebase over to using a newer and recommended replacement for StyleCop, called StyleCopAnalyzers.
StyleCopAnalyzers is an implementation of the StyleCop rules based on Roslyn Analyzers (Rosyln is the name of the C# compiler). The primary difference between StyleCop and StyleCopAnalyzers is that with StyleCop the rules are run through an external tool, whereas with StyleCopAnalyzers the rules are instead implemented as analyzers that are executed as extentions to the C# compiler itself. In practice this provides a cohesive, simplified, and powerful user experience, by integrating the installation of StyleCop rules execution directly into the project itself as a NuGet package, the configuration of rules through the code analysis rule set configuration file and its user interface, and automated refactorings for fixing violations across the entire codebase.
The installation of the StyleCop Analyzers was as simple as adding a NuGet package reference to StyleCop.Analyzers in each project:
Once installed, the full list of available StyleCop Analyzers is visible in the Analyzers node beneath the project’s references:
To achieve consistency of the same rules being applied across all projects, their project files are all referencing the same rule set file stored in the Build folder:
Including a new StyleCop rule into the build process and fixing it is a simple process:
- Open the rule set via the Code Analysis page of a project (the open button in the previous image).
- Select a new rule in the StyleCop.Analyzers node (I initially set the action to Error to easily spot new violations during the build, and set the rule to Warning when they’re fixed).
- Build the solution, see the errors/warnings.
- Go to one of the errors and use the code fix to fix all occurrences in the solution.
- Build the project to verify the errors/warnings are gone, review the changes, and commit them.
With these changes I think it is now relatively straightforward to continue using StyleCop rules to ensure adherence to a common coding style that will improve the readability of the codebase.