At work, my team recently developed a custom MSBuild task designed to extract the OpenAPI specification from an ASP.NET Core application during compilation and validate it against our API design guidelines with Spectral.
When a Spectral rule is violated, the MSBuild task generates a warning. To ensure developers fix these issues, we planned for these warnings to be treated as errors in their CI pipeline. To achieve this, we relied on the TreatWarningsAsErrors property, which is already widely used in our projects.
Surprisingly, we discovered that the build of some projects did not fail despite the presence of warnings related to non-compliance with the OpenAPI specification. Here are the findings of my investigation.
TreatWarningsAsErrors only impacts the C# compiler
Indeed, the Microsoft documentation is clear on this matter:
TreatWarningsAsErrorsonly impacts the C# compiler, not any other MSBuild tasks in your csproj file. Thewarnaserrorcommand line switch impacts all tasks.
If you want to ensure that there are absolutely no warnings in your build, you must include the -warnaserror argument:
dotnet build -warnaserror
-warnaserror can produce output on errors, TreatWarningsAsErrors does not
The same documentation states:
Secondly, the compiler doesn’t produce any output on any warnings when
TreatWarningsAsErrorsis used. The compiler produces output when thewarnaserrorcommand line switch is used.
If you still wish to produce an assembly, despite there being warnings treated as errors, you can set TreatWarningsAsErrors to false and use -warnaserror instead.
Buy me a coffee