FAQ for code analysis in Visual Studio

Code analysis and EditorConfig files work hand-in-hand. When you define code styles in an EditorConfig file or on the text editor Options page, you're actually configuring the code analyzers that are built into Visual Studio. EditorConfig files can be used to enable or disable analyzer rules, and also to configure NuGet analyzer packages.

Rule sets and EditorConfig files can coexist and can both be used to configure analyzers. Both EditorConfig files and rule sets let you enable and disable rules and set their severity.

However, in Visual Studio 2019 version 16.5 and later, rule set files are deprecated in favor of EditorConfig files, and .NET Core and .NET 5+ projects don't support all the rule set menu commands. For more information, see Convert an existing rule set file to an EditorConfig file.

EditorConfig files offer additional ways to configure rules:

• For the .NET code-quality analyzers, EditorConfig files let you define which types of code to analyze.
• For the .NET code-style analyzers and .NET code-quality analyzers, EditorConfig files let you define the preferred code styles for a codebase.

In addition to rule sets and EditorConfig files, some analyzers are configured through the use of text files marked as additional files for the C# and VB compilers.

Yes. For analyzers that are installed with .NET SDK 5.0 or higher, or from a NuGet package, those rules are enforced at build time, including during a CI build. Analyzers used in CI builds respect rule configuration from both rule sets and EditorConfig files. Starting with .NET 5.0, the code style analyzers that are built into Visual Studio are also included in the .NET SDK, and most of them are enforceable in a CI build. For more information, see Enable on build.

The Visual Studio IDE includes built-in analyzers that look for both code style and quality issues. These rules help you use new language features as they're introduced and improve the maintainability of your code. IDE analyzers are continually updated with each Visual Studio release.

StyleCop analyzers are third-party analyzers installed as a NuGet package that check for style consistency in your code. In general, StyleCop rules let you set personal preferences for a code base without recommending one style over another.

.NET Compiler Platform-based code analysis analyzes source code in real time and during compilation, whereas legacy analysis analyzes binary files after build has completed. For more information, see .NET Compiler Platform-based analysis versus legacy analysis.

Both FxCop analyzers and .NET analyzers refers to the .NET Compiler Platform ("Roslyn") analyzer implementations of FxCop CA rules. Prior to Visual Studio 2019 16.8 and .NET 5.0, these analyzers shipped as Microsoft.CodeAnalysis.FxCopAnalyzers NuGet package. Starting in Visual Studio 2019 16.8 and .NET 5.0, these analyzers are included with the .NET SDK. They're also available as Microsoft.CodeAnalysis.NetAnalyzers NuGet package. Please consider migrating from FxCop analyzers to .NET analyzers.

To prevent code analysis warnings from being treated as errors, follow these steps:

1. Create a .props file with the following content:

   <Project>
      <PropertyGroup>
         <CodeAnalysisTreatWarningsAsErrors>false</CodeAnalysisTreatWarningsAsErrors>
      </PropertyGroup>
   </Project>
   

2. Add a line to your .csproj or .vbproj project file to import the .props file you created in the previous step. This line must be placed before any lines that import the analyzer .props files. For example, if your .props file is named codeanalysis.props:

   ...
   <Import Project="..\..\codeanalysis.props" Condition="Exists('..\..\codeanalysis.props')" />
   <Import Project="..\packages\Microsoft.CodeAnalysis.NetAnalyzers.5.0.0\build\Microsoft.CodeAnalysis.NetAnalyzers.props" Condition="Exists('..\packages\Microsoft.CodeAnalysis.NetAnalyzers.5.0.0\build\Microsoft.CodeAnalysis.NetAnalyzers.props')" />
   ...
   

The Code Analysis property page at the solution level was removed in favor of the more reliable shared property group. For managing Code Analysis at the project level, the Code Analysis property page is still available. (For managed projects, we also recommend migrating from rulesets to EditorConfig for rule configuration.) For sharing rulesets across multiple/all projects in a solution or a repo, we recommend defining a property group with CodeAnalysisRuleSet property in a shared props/targets file or Directory.props/Directory.targets file. If you don't have any such common props or targets that all your projects import, you should consider adding such a property group to a Directory.props or a Directory.targets file at a top level solution directory, which is automatically imported in all project files defined in the directory or its sub-directories.

See also

• Analyzers overview
• .NET coding convention settings for EditorConfig