Re: ul
Saverio Lazaro
A key difference is that StyleCop analyzes C# source code. FxCop analyzes .NET assemblies after they are compiled, it works for any language. Accordingly, StyleCop is picky about how your source code looks. FxCop is picky about how you use the .NET framework classes. They complement each other.
They are different tools. StyleCop is focused on code style. You can check doc. comments, naming convention, spacing, etc. Altough it can do almost the same things as StyleCop, FxCop is focused on the Microsoft Design Guidelines. It will analyze your code looking for possible performance and security issues, among other things.
I never wrote rules for any of them, but I believe that you should go for the one that does exactly what you want (if just coding standards, go with StyleCop, otherwise, go with FxCop). This way, you'll probably feel more confortable with the API.
.NET compiler platform (Roslyn) analyzers inspect your C# or Visual Basic code for code quality and style issues. Starting in .NET 5, these analyzers are included with the .NET SDK and you don't need to install them separately. If your project targets .NET 5 or later, code analysis is enabled by default. If your project targets a different .NET implementation, for example, .NET Core, .NET Standard, or .NET Framework, you must manually enable code analysis by setting the EnableNETAnalyzers property to true.
If you don't want to move to the .NET 5+ SDK, have a non-SDK-style .NET Framework project, or prefer a NuGet package-based model, the analyzers are also available in the Microsoft.CodeAnalysis.NetAnalyzers NuGet package. You might prefer a package-based model for on-demand version updates.
.NET analyzers are target-framework agnostic. That is, your project does not need to target a specific .NET implementation. The analyzers work for projects that target .NET 5+ as well as earlier .NET versions, such as .NET Core 3.1 and .NET Framework 4.7.2. However, to enable code analysis using the EnableNETAnalyzers property, your project must reference a project SDK.
If rule violations are found by an analyzer, they're reported as a suggestion, warning, or error, depending on how each rule is configured. Code analysis violations appear with the prefix "CA" or "IDE" to differentiate them from compiler errors.
Code quality analysis ("CAxxxx") rules inspect your C# or Visual Basic code for security, performance, design and other issues. Analysis is enabled, by default, for projects that target .NET 5 or later. You can enable code analysis on projects that target earlier .NET versions by setting the EnableNETAnalyzers property to true. You can also disable code analysis for your project by setting EnableNETAnalyzers to false.
Analysis mode refers to a predefined code analysis configuration where none, some, or all rules are enabled. In the default analysis mode (Default), only a small number of rules are enabled as build warnings. You can change the analysis mode for your project by setting the property in the project file. The allowable values are:
Starting in .NET 6, you can omit in favor of a compound value for the property. For example, the following value enables the recommended set of rules for the latest release: latest-Recommended. For more information, see AnalysisLevel.
If you use the -warnaserror flag when you build your projects, all code analysis warnings are also treated as errors. If you do not want code quality warnings (CAxxxx) to be treated as errors in presence of -warnaserror, you can set the CodeAnalysisTreatWarningsAsErrors MSBuild property to false in your project file.
By default, you'll get the latest code analysis rules and default rule severities as you upgrade to newer versions of the .NET SDK. If you don't want this behavior, for example, if you want to ensure that no new rules are enabled or disabled, you can override it in one of the following ways:
Set the AnalysisLevel MSBuild property to a specific value to lock the warnings to that set. When you upgrade to a newer SDK, you'll still get bug fixes for those warnings, but no new warnings will be enabled and no existing warnings will be disabled. For example, to lock the set of rules to those that ship with version 5.0 of the .NET SDK, add the following entry to your project file.
Install the Microsoft.CodeAnalysis.NetAnalyzers NuGet package to decouple rule updates from .NET SDK updates. For projects that target .NET 5+, installing the package turns off the built-in SDK analyzers. You'll get a build warning if the SDK contains a newer analyzer assembly version than that of the NuGet package. To disable the warning, set the _SkipUpgradeNetAnalyzersNuGetWarning property to true.
If you install the Microsoft.CodeAnalysis.NetAnalyzers NuGet package, you should not add the EnableNETAnalyzers property to either your project file or a Directory.Build.props file. When the NuGet package is installed and the EnableNETAnalyzers property is set to true, a build warning is generated.
Starting in .NET 5, you can enable code-style analysis on build, both at the command line and inside Visual Studio. Code style violations appear as warnings or errors with an "IDE" prefix. This enables you to enforce consistent code styles at build time.
With the .NET 5 SDK and later versions, you can enable code-style analysis when building from the command-line and in Visual Studio. (However, for performance reasons, a handful of code-style rules will still apply only in the Visual Studio IDE.)
At my last job we ran a continuous integration server with CruiseControl.NET. As part of each build we did code analysis with FxCop. (We also ran StyleCop, but that was only to run one custom rule to address a problem we were having.) FxCop is a tool that analyzes .NET assemblies for potential design, localization, performance, and security problems. Most of these rules are pulled from Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, which serves as the de-facto style guidelines in many .NET shops. (We used it to avoid petty formatting arguments. Whatever FDG said was the decider unless we unanimously disagreed.)
One criticism of FxCop is its unwieldy XML files. Depending on the size of your code base and your configuration it is easy to end up with XML files running into the tens of megabytes. Perl::Critic, like most UNIX tools, disdains the use of XML (usually a plus) and instead outputs violations one to a line. Both tools let you configure which rules/policies to include with each run. FxCop throws these into the same massive .fxcop XML file while Perl::Critic looks for an INI-style file called .perlcriticrc in your home directory. Speaking of that massive XML file, FxCop also has a nasty habit of rewriting its XML results and configuration across runs, leading to some nasty conflicts if you have multiple developers committing changes simultaneously.
I love automation. Part of the glory of seeing a green build is to also know that it has passed some type of quality gates. In this post I'll talk a bit about some of my favorite Code Analysis tools for .NET Core. I use them in both personal as well as work projects, in a varietal mix depending on project. It's not an exhaustive list, and by no means the only tools that can be used. These are a select part of my arsenal to ensure I stay on the right path when developing software.
Software evolved quickly, both internally developed and third-party software. To stay up to date with all the frequent changes, we need to automate certain aspects of our development and operations work.
Continuously seeing an increase in code changes without understanding what those changes are doing, can quickly lead to possible bugs, application failures and vulnerabilities. These are risks at various levels - corporate data exposure risks, business continuity risks, delays in releases, and a lot more.
At the team, or organizational level, you can define a set of policies and rules that should apply to all the code your team(s) write and commit to your code repositories. This means that you can also centrally track, and approve or reject changes that will fly into your production workloads, depending on the quality report of a build.
That said, code analysis isn't something that magically makes your applications work like a greased machine all by itself. It should be considered as a helping hand, but in the end, you still need to ensure that the output of the code analysis reports are true, do not contain false positives, and that you get value to your organization and wider teams - not just use it as a number-driven report to show on a slide deck. Getting reports without taking action is like knowing the ship is sinking due to holes in the hull, but just looking at the holes or ignoring them, instead of helping repair them.
This does not come with a requirement to add any dependencies to your solutions and projects. Instead, the code analysis tools run from your developer box when you want them to. Most often when you build your code, or if it is a Linter, it runs as you type.
This creates a dependency on the NuGet analyzers in your projects, but comes with the convenience that regardless if you build locally or on a build agent, you get the same analyzers applied to the code base.
We can run a lot more tools here than the NuGet analyzers, of course. We can run third party Application Vulnerability Scanners, and a lot more great tools to help us stay safer as we deploy more code.
When you have complex solutions, or even simple solutions that depend on code outside of your comfort zone or knowledge, this tool is great for understanding where you could have potential thread blockers and other async-related issues.
I find it useful when I need to improve my coding style, help with correctness or generally find how I can write code better and smarter. It can result in "alert fatigue" in the sense that you can get a lot of warnings for things you may not care about, which is why the ignore options are important to master.
7fc3f7cf58