Configuring Errors and Warnings in C#

Configuring Errors and Warnings in C#

I recently stumbled upon some code that was making an awaitable method call but was not being awaited. I noticed the issue because it was a compiler warning CS4014 and was highlighted in code. I immediately fixed the issue, however, my second action was configuring errors and warnings in C#.


Make sure to check out my YouTube channel where I often post related content that accompanies my blog posts.


You can have a .NET build fail by having the compitler producing errors for normally what are considered warnings. Such as as CS4014

Because this call is not awaited, execution of the current method continues before the call is completed. Consider applying the ‘await’ operator to the result of the call.

The code in question looked something similar to this as I seen within Rider

There are very few cases where I would not want to await. Because of that, I wanted this to cause a compiler error so going forward it was impossible to do this by accident and not notice.

The fix is really simple, in your SDK style csproj file, specify an element called WarningAsError inside a PropertyGroup. The value is a comma-separated list of warning numbers to treat as errors.

Now when you look or build it produces an error instead of a warning.

The great thing about Roslyn analyzers is they are also helpful in finding possible code issues. One of my favorites is the Microsoft.VisualStudio.Threading.Analyzers that is available as a NuGet package. Simply add it to your project and you’ll immediately get over a dozen analyzer rules applied to your codebase. The package is best for detecting Sync over Async which I’ve written about before.

One of them is VSTHRD103 that finds any code that synchronously blocks. using Wait() on Task is a good example.

We can also turn this into an error by adding VSTHRD103 in our WarningAsErrors list.


However, when you start adding some Roslyn analyzers you may not like some of the warnings they provide. One for me, which is highly debated, is the use of the Async suffix. Since our entire codebase is Async, we do not follow this convention. This is rule VSTHRD200 which I did not want to be warned about. This is also pretty simple by adding a NoWarn element.


The last tip is instead of specifying all of these in each project file (csproj) definition, you can create a file called Directory.Build.props and place it at the root of where your solution is located. This file will then apply to every project.

Configuring Errors and Warnings in C#

Do you have any preferred Roslyn analyzers or warnings you like to treat as errors? Let me know in the comments or on Twitter.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.