dotnet "TreatWarningsAsErrors" Breaks the Build in CI
The project (or build invocation) sets TreatWarningsAsErrors, so any compiler warning becomes a build-breaking error. A warning that prints harmlessly on a developer machine fails CI outright.
What this error means
Build fails with a CSxxxx reported as an error, and the log shows it was promoted from a warning. Disabling TreatWarningsAsErrors makes it "pass" locally, which confirms the policy is what fails the build.
error CS0168: The variable 'ex' is declared but never used
[warnings treated as errors due to TreatWarningsAsErrors]Common causes
A real warning under a strict policy
With TreatWarningsAsErrors=true, even minor warnings (unused variable, obsolete API) fail the build. The warning is genuine; the policy just makes it fatal.
New warnings from a compiler or dependency bump
A newer SDK/compiler or an upgraded package introduces new warnings (e.g. nullable, obsolete) that were not present before, breaking a previously green build.
How to fix it
Fix the underlying warning
Address the warning at its source - it is the correct, durable fix rather than suppressing the policy.
// CS0168: remove the unused variable, or use a discard
catch (Exception) // was: catch (Exception ex)
{
// handle without the unused binding
}Scope specific codes out of the policy
When a warning is intentional, exclude that code narrowly instead of disabling the whole policy.
<PropertyGroup>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<WarningsNotAsErrors>$(WarningsNotAsErrors);CS0618</WarningsNotAsErrors>
</PropertyGroup>How to prevent it
- Build locally with the same warning policy CI uses so warnings surface before push.
- Fix warnings rather than broadly suppressing them.
- Pin the SDK so a compiler bump does not silently introduce new warnings.