What analysers run during a .NET build, how do IDE code style rules differ from CA code quality rules, and how do you configure them across a team?

1. Where analysers run

                     Roslyn compilation (CoreCompile -> Csc)
   source + references + analyser assemblies (SDK + NuGet analyzers/ folders)
                              |
            +-----------------+------------------+
            |                                    |
      Compiler diagnostics                 Analyser diagnostics
      CS0xxx, CS8xxx (nullable)            CA   (SDK code quality, NetAnalyzers)
                                           IDE  (code style) -- build only if EnforceCodeStyleInBuild
                                           SA / RCS / MA / RS (packages)
            |                                    |
            +---------------+--------------------+
                            v
   severity from: .editorconfig / .globalconfig  >  AnalysisLevel + AnalysisMode defaults
   then:          NoWarn (drop)   WarningsAsErrors / TreatWarningsAsErrors (promote)
                            |
          IDE: squiggles + quick fixes        Build: warnings or errors in the output

Analysers are .NET assemblies loaded into the compiler. The IDE runs them live on open files (and optionally the whole solution in the background); the build runs them inside CoreCompile. Source generators are loaded the same way.

2. The families

The SDK's CA analysers are versioned with the SDK. To get newer rules without a new SDK, reference the Microsoft.CodeAnalysis.NetAnalyzers package explicitly.

CA categories worth knowing

3. AnalysisLevel and AnalysisMode

<PropertyGroup>
  <AnalysisLevel>10.0</AnalysisLevel>          <!-- which version of the rule set -->
  <AnalysisMode>Recommended</AnalysisMode>     <!-- how many rules are on as warnings -->
  <!-- or combined: <AnalysisLevel>10.0-recommended</AnalysisLevel> -->
  <AnalysisModeSecurity>All</AnalysisModeSecurity>   <!-- per-category override -->
</PropertyGroup>

4. Severities in .editorconfig

Three levels of precision, most specific wins:

[*.cs]
dotnet_analyzer_diagnostic.severity = suggestion                 # every analyser rule
dotnet_analyzer_diagnostic.category-Security.severity = error     # a whole category
dotnet_diagnostic.CA2007.severity = none                          # one rule

Code style rules have two parts: the preference and the severity.

csharp_style_namespace_declarations = file_scoped:warning   # preference + severity shorthand
dotnet_diagnostic.IDE0161.severity = warning                # explicit severity (wins in the build)

Set the dotnet_diagnostic severity explicitly for rules you want in the build; the :warning shorthand isn't always honoured by the command-line build.

The IDE0005 trap

"Remove unnecessary usings" (IDE0005) only reports in the build when GenerateDocumentationFile is true, because the compiler needs documentation-comment analysis to know a using is unused. Teams often enable the rule and wonder why CI never reports it.

5. Sharing configuration across a team

A shared package (for example Contoso.CodeStandards) that contains a .globalconfig, analyser references and a .props file lets many repositories adopt the same baseline and upgrade it with one version bump.

6. Suppressing narrowly

Always restore a #pragma, always add a justification, and review suppressions like code.

7. Rolling out stricter rules

 1. pick the rules (security and reliability first, then performance, then style)
 2. set them to suggestion -> see the count, nobody's build breaks
 3. fix mechanically where possible: dotnet format analyzers --diagnostics CA1822 IDE0161
 4. raise to warning; fix the rest in small PRs per area
 5. raise to error for rules that catch real bugs
 6. upgrade AnalysisLevel in its own PR on each SDK upgrade, repeat

Track the warning count per project over time. A number that only goes down is the best evidence the rollout is working.

8. Performance

• Analysers run inside every compilation. Large third-party packs on big solutions can add minutes.
• Build with -p:ReportAnalyzer=true -bl and open the binary log: it shows the time each analyser took.
• RunAnalyzersDuringBuild=false (or -p:RunAnalyzers=false) speeds up a quick local build, as long as CI still runs them.
• In the IDE, limit background analysis to open documents on very large solutions.

9. Security

• Turn on the security category (AnalysisModeSecurity=All) and make it an error on main. Rules such as CA2100 (SQL injection), CA3001 to CA3012 (taint analysis for injection) and CA5350/CA5351 (weak hashing and encryption) are cheap insurance.
• Microsoft.CodeAnalysis.BannedApiAnalyzers with a BannedSymbols.txt can ban dangerous APIs, such as BinaryFormatter or direct HttpClient construction, across the codebase.
• Analyser packages run code inside your build. Take them from trusted publishers and pin their versions like any other dependency.

10. .NET 11 awareness

The .NET 11 SDK will ship a new rule set (AnalysisLevel 11.0) with new CA rules. With a pinned level, upgrading the SDK doesn't change your warnings; raise the level in a separate PR once you've reviewed the new rules. Keep production on the .NET 10 SDK until then.

11. Try it yourself

1. Create a console app with a block-scoped namespace and a string.Format without a culture, then build and note the warnings.
2. Add <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild> and dotnet_diagnostic.IDE0161.severity = warning, and build again.
3. Add an unused using and enable IDE0005 at warning; build with and without GenerateDocumentationFile.
4. Set <AnalysisLevel>10.0-all</AnalysisLevel> and count the new warnings, then go back to recommended.
5. Add dotnet_analyzer_diagnostic.category-Security.severity = error and write a SqlCommand with string concatenation to trigger CA2100.
6. Relax CA1707 for a [tests/**.cs] section and confirm it only applies to tests.
7. Build with -p:ReportAnalyzer=true -bl and find the slowest analyser in the binary log.

<!-- Directory.Build.props -->
<Project>
  <PropertyGroup>
    <AnalysisLevel>10.0-recommended</AnalysisLevel>
    <AnalysisModeSecurity>All</AnalysisModeSecurity>
    <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  </PropertyGroup>
</Project>

<!-- Directory.Packages.props: a third-party analyser for every project (private to each project) -->
<ItemGroup>
  <GlobalPackageReference Include="StyleCop.Analyzers" Version="1.1.118" />
</ItemGroup>

# .editorconfig
root = true

[*.cs]
csharp_style_namespace_declarations = file_scoped:warning
dotnet_diagnostic.IDE0161.severity = warning
dotnet_diagnostic.CA1848.severity = warning
dotnet_diagnostic.CA2100.severity = error
dotnet_diagnostic.CA2007.severity = none

[tests/**.cs]
dotnet_diagnostic.CA1707.severity = none

using System.Diagnostics.CodeAnalysis;

namespace Orders.Data;

public sealed class ConnectionFactory
{
    [SuppressMessage("Reliability", "CA2000:Dispose objects before losing scope",
        Justification = "The caller owns and disposes the returned connection.")]
    public SqlConnection Create(string connectionString) => new(connectionString);
}

The last example assumes a reference to Microsoft.Data.SqlClient and using Microsoft.Data.SqlClient;.