installer: warnaserror not failing the build with exit 1 if only errors present were warnings

When there are no errors in a build, but only warnings that have been promoted to error with WarnAsError then the build will not fail with an exit of 1.

$ dotnet build --no-incremental /WarnAsError

...

Build FAILED.

....cs(28,1): error SA1507: Code must not contain multiple blank lines in a row [....csproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:01.55
Exit code =>  0

Given that there are errors in the build, would expect an exit code of 1

Note that if there are genuine errors in the build, the build will fail correctly with the correct exit code

OS: Linux Ubuntu 18.04 dotnet version: 2.2.3-preview

About this issue

Original URL
State: open
Created 5 years ago
Reactions: 14
Comments: 29 (3 by maintainers)

Most upvoted comments

I just got it today with .net 6 😦

mungojam on Feb 10, 2022

I thought of a good workaround that I am now using in my application at work.

The behavior I want is to allow warnings on developer machines but treat warnings as errors on our build server. The configuration on a developer machine is Debug and the configuration on the build server is Release. Therefore, doing this in each project files achieves the behavior that I want.

<PropertyGroup Condition="'$(Configuration)' != 'Debug'">
  <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>

I haven’t noticed this approach exhibiting the bug described in this issue.

TysonMN on Sep 15, 2020

I researched various dotnet sdks en think the issue was introduced in the 2.2.2* series/ since msbuild 16.0.450+ga8dc7f1d34: 2.2.101 works; msbuild: 15.9.20+g88f5fadfbe 2.2.104 works; msbuild: 15.9.20+g88f5fadfbe 2.2.202 flaky; msbuild: 16.0.450+ga8dc7f1d34 2.2.203 flaky; msbuild: 16.0.450+ga8dc7f1d34 2.2.300 flaky; msbuild: 16.1.76+g14b0a930a7 2.2.301 flaky; msbuild: 16.1.76+g14b0a930a7 3.0-preview untested

Hopes this helps in tracking down the issue.

@BTSmolders identified 2.2.202 as the earliest SDK he tested that exhibited the bug, but there were more SDKs that could have been tested. I think I have tested all the relevant ones, and I would like to share what I learned.

2.1.602 exhibited the bug for me
2.1.506 worked for me
2.1.600-preview-009426 worked for me

The git history of tag 2.1.602 has no parallel branches at tag v2.1.500. The released SDKs between those two tags form two parallel branches: the “2.1.600-preview-009426 branch” and the “2.1.50X branch”. The last 2.1.50X release before the release of 2.1.602 was 2.1.506.

In summary, I think the bug was introduced somewhere before 2.1.602 and after 2.1.600-preview-009426 and 2.1.506.

I tested all these SDKs on Azure DevOps using the Use .NET Core task.

TysonMN on Oct 6, 2019

Still happening in 6.0.401.

simonvane on Oct 4, 2022

The behavior I want is to allow warnings on developer machines but treat warnings as errors on our build server.

This is exactly the behavior I want as well. It’s just really unfortunate we have to use a workaround, instead of just having the feature working as expected.

Thanks for pointing out the workaround, though! 👍

jpactor on Sep 23, 2020

I was able to reproduce it here:

I am not sure if it happened by accident, but this repo started to show the behavior when the only warning started with CSC. In my company projects it’s reproduced also when there are warnings without the CSC start (but it’s in a on-premise installation of Azure DevOps).

pleonex on Apr 28, 2020

I researched various dotnet sdks en think the issue was introduced in the 2.2.2* series/ since msbuild 16.0.450+ga8dc7f1d34: 2.2.101 works; msbuild: 15.9.20+g88f5fadfbe 2.2.104 works; msbuild: 15.9.20+g88f5fadfbe 2.2.202 flaky; msbuild: 16.0.450+ga8dc7f1d34 2.2.203 flaky; msbuild: 16.0.450+ga8dc7f1d34 2.2.300 flaky; msbuild: 16.1.76+g14b0a930a7 2.2.301 flaky; msbuild: 16.1.76+g14b0a930a7 3.0-preview untested

Hopes this helps in tracking down the issue.

BTSmolders on Jul 11, 2019