In my project's settings in Visual Studio, I have set 'Treat warnings as errors' to 'All'. The Warning level is set to 4. I tested this by deliberately introducing code that violates CA1305, but it builds (and rebuilds) successfully, returning a Warning. What I expected was that the build would fail and an Error would be returned. Is my understanding wrong?

- 106,458
- 22
- 256
- 341

- 195
- 1
- 4
- 12
-
Do you have any `pragmas` that explicitly disable that warning? – Chris O Jan 16 '13 at 19:27
2 Answers
Code Analysis uses a different mechanism to treat warnings as errors. To have Code Analysis warnings treated as such, add a new Code Analysis Ruleset to your solution. To do so, rightclick your solution and choose "Add new item...". Search for "Rule Set" and select to add a new "Code Analysis Rule Set". Give it any name you want.
In the Rule Set Editor, select the rules you want to include in your project and set them to Error. You can choose which rules to treat as errors and which as warnings.
Set the name for the rule set in the Code Analysis Ruleset properties window and save it. Then open the Analyze->Configure Code Analysis for Solution
menu item.
Select your "As Error" ruleset for your projects and apply.

- 106,458
- 22
- 256
- 341
You could use the "CodeAnalysisTreatWarningsAsErrors" property in your csproj-file like described here:
For Visual Studio 2008, we have added a new MSBuild property that allows you to easily treat all Code Analysis warnings as build errors. This can be useful for example, if you want to force that any firing of a Code Analysis rule to break the build during a nightly Team Build without needing to individually set this for every rule.
To use, simply add the property to your project file (or a common targets file) and set it to true:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
<PropertyGroup>
[...]
<!-- either here -->
<CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
[...]
<!-- or here ... -->
<CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
[...]
<!-- and here -->
<CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors>
</PropertyGroup>
[...]
</Project>
This can be used with in combination with <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings>
, which will have the same effect on StyleCop warnings.

- 441
- 4
- 6
-
1Any idea why this wouldn't work for class library, but does for ms test project? exact same configuration same code in both projects .... but CA warnings do not break the class lib project build... – Michiel Cornille Jan 17 '17 at 11:17
-
Id you did enable CA in the class library properties for the required configuration (Debug/Release)? The specified rule set actually does have warnings? And you double checked the *.csproj-files for typos? Otherwise, nope, no idea. Sorry. I use this in all kinds of *.csproj in VS/TFS 2010, VS/TFS 2013, VS/TFS 2015 and the type never seemed to effect those settings. – TiltonJH Jan 20 '17 at 10:08
-
PS: The build itself (creating the assembly) is not effected, because it is performed by the compiler. However after the compiler the "FxCop.exe" is run and it produces the CA Warnings/Errors. And this in turn stops the build process. – TiltonJH Jan 20 '17 at 10:12
-
for me I just needed to add the new boolean to the single "Globals" PropertyGroup. hopefully that's not overly-simplistic. – orion elenzil Jan 06 '21 at 19:25
-
It is not overly-simplistic ;-) . It is quite right actually. However, this solution is for older project types. In newer SDK projects it is better to use the 'newer' analyzers. The old classic `FxCop.exe` and `StyleCop.exe` are now considered deprecated. The 'new' analyzers do not care about `CodeAnalysisTreatWarningsAsErrors` or `StyleCopTreatErrorsAsWarnings` but can be configured using the `.editorconfig`. – TiltonJH Jan 25 '21 at 22:41