Review this Directory.Build.props that turns on TreatWarningsAsErrors with a long NoWarn list. What would you change, and how should warnings-as-errors be used in a team?

1. Who produces warnings in a .NET build

A single dotnet build collects diagnostics from several producers, and they don't all obey the same switches:

The last row surprises people: TreatWarningsAsErrors doesn't promote MSBuild's own warnings, such as MSB3277 assembly version conflicts. Use MSBuildTreatWarningsAsErrors for those, or dotnet build -warnaserror in CI, which applies to everything.

2. How a diagnostic ends up as an error, a warning or nothing

        diagnostic produced (compiler or analyser), default severity
                              |
   .editorconfig / .globalconfig severity for this file?
          none | silent | suggestion | warning | error
                              |
                              v
                     effective severity
                              |
   #pragma warning disable or [SuppressMessage] here? --yes--> suppressed
                              | no
        NoWarn contains ID? --yes--> dropped (not reported at all)
                              | no
        WarningsAsErrors contains ID (or 'nullable')? --yes--> error
                              | no
        TreatWarningsAsErrors = true?
              | yes                                   | no
              v                                       v
   WarningsNotAsErrors contains ID?               warning
        | yes -> warning   | no -> error

Three consequences:

• TreatWarningsAsErrors only promotes things that are warnings. A rule set to suggestion in .editorconfig stays a suggestion, so you can keep a rule visible in the IDE without blocking the build.
• NoWarn is the bluntest tool: the diagnostic disappears from every log, every report and every IDE.
• WarningsNotAsErrors keeps a diagnostic visible as a warning, which is usually what you want for known debt.

3. The suppression tools, from narrowest to widest

When you use pragmas, turn on IDE0079 ("remove unnecessary suppression") so suppressions that no longer hide anything get cleaned up.

4. Why AnalysisLevel must be pinned with warnings as errors

 AnalysisLevel=latest-all + TreatWarningsAsErrors=true

   SDK 10.0.1xx  -->  rules A, B, C enabled           build green
   SDK 10.0.2xx  -->  rules A, B, C, D enabled        build RED, no code changed

 AnalysisLevel=10.0-recommended

   SDK 10.0.2xx  -->  rule set frozen at 10.0          build green
   later: a pull request changes it to 11.0-recommended and fixes the new warnings

latest follows whichever SDK happens to build the code, so an agent image update or a new developer machine can break the build. A pinned value like 10.0-recommended makes the rule set part of the source, and upgrading it becomes a reviewed change. Pin the SDK in global.json as well, because new compiler warnings can arrive with a new SDK band even when AnalysisLevel is pinned.

5. NuGet audit warnings

NuGet checks restored packages against known vulnerabilities:

Related properties: NuGetAudit (on by default), NuGetAuditLevel (minimum severity reported) and NuGetAuditMode (direct or all; the .NET 10 SDK audits transitive packages too by default).

A sensible policy is to make NU1903 and NU1904 errors with WarningsAsErrors, keep NU1901 and NU1902 as visible warnings with an owner, and never put any of them in NoWarn. When a specific advisory doesn't apply to you, suppress that advisory with <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-..." /> and a comment, rather than hiding every future vulnerability of that severity.

6. Local versus CI enforcement

If only CI promotes warnings to errors (Condition="'$(CI)' == 'true'"), developers get a green local build and a red pipeline about ten minutes later. The feedback loop gets longer and pull requests pick up "fix warnings" commits.

Use the same settings everywhere. If strictness gets in the way of quick experiments, the IDE's error list shows the problems as you type, and a developer can still build a scratch branch with -p:TreatWarningsAsErrors=false on purpose. The default should be identical.

7. Ratcheting a legacy codebase

 week 0   measure: warnings per project (build log or SARIF)
            Orders.Api 412   Billing 37   Shared 0   Reports 1,980
 week 1   Shared: TreatWarningsAsErrors=true (already at zero)
          everyone: WarningsAsErrors=nullable;CA2100;CA3001;NU1903;NU1904
          CI: fail if any project's count goes UP
 week n   Billing reaches 0 -> strict; Orders.Api 412 -> 120 -> 0 -> strict
 end      TreatWarningsAsErrors in Directory.Build.props, opt-ins deleted

To produce countable output, set <ErrorLog>$(MSBuildProjectName).sarif,version=2.1</ErrorLog> so the compiler writes a SARIF file per project, or build with -bl and inspect the binary log. A small script compares the counts with a baseline file committed in the repo and fails when any number rises. Lower the baseline in the same pull request that fixes warnings.

8. Diagnosis

9. Performance and security

• Promoting warnings to errors has no build-time cost. Enabling more analysers does (see the analyser question), so measure with -p:ReportAnalyzer=true if builds slow down.
• Security rules (CA2100, CA3001-CA3012 injection rules, CA5xxx cryptography rules) and high and critical NuGet audit findings should be errors and should never appear in NoWarn.
• Build files decide what the compiler is allowed to tell you, so put Directory.Build.props, Directory.Build.targets and .editorconfig under CODEOWNERS.

10. .NET 11 awareness

.NET 11 (due in November 2026, an STS release with 24 months of support, currently in preview and release candidates) will add analyser rules and compiler warnings, as every release does. With AnalysisLevel and global.json pinned to .NET 10, they reach the build only when a pull request raises the pins and fixes what appears.

11. Try it yourself

1. Create a project with Nullable enabled and a method that dereferences a string?.
2. Build with -p:TreatWarningsAsErrors=true and see CS8602 as an error.
3. Add <WarningsNotAsErrors>CS8602</WarningsNotAsErrors> and build: it's a warning again.
4. Replace it with <NoWarn>CS8602</NoWarn> and build: the warning is gone entirely, including from the IDE.
5. Add <ErrorLog>$(MSBuildProjectName).sarif,version=2.1</ErrorLog>, remove NoWarn, build and open the SARIF file to see a countable list.
6. Reference a package version with a known advisory and watch NU1903 or NU1904 appear during restore; then add it to WarningsAsErrors and see restore fail.

<!-- Directory.Build.props: repo-wide defaults (evaluated BEFORE each project file) -->
<Project>
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <AnalysisLevel>10.0-recommended</AnalysisLevel>
    <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>

    <!-- Always errors, in every project -->
    <WarningsAsErrors>$(WarningsAsErrors);nullable;CA2100;NU1903;NU1904</WarningsAsErrors>
  </PropertyGroup>
</Project>

<!-- Directory.Build.targets: evaluated AFTER each project file, so it can see the project's opt-in -->
<Project>
  <PropertyGroup Condition="'$(StrictWarnings)' == 'true'">
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <WarningsNotAsErrors>$(WarningsNotAsErrors);CS0618</WarningsNotAsErrors> <!-- tracked: TICKET-1234 -->
  </PropertyGroup>
</Project>

<!-- A project that reached zero warnings opts in -->
<PropertyGroup>
  <StrictWarnings>true</StrictWarnings>
</PropertyGroup>

The opt-in condition lives in Directory.Build.targets because a condition in Directory.Build.props would run before the project file sets StrictWarnings, and would never match. Once every project has opted in, move TreatWarningsAsErrors into Directory.Build.props and delete the opt-in.