Code Focused
Hide Compiler Warnings in Your Spare Time
Learn how to keep new code-style warnings from filling up your formerly pristine Visual Studio Error List panel.
As Microsoft .NET Framework languages have grown in functionality, they’ve started tossing out compiler warnings like your development life depended on it. Messages about unused variables can sometimes help locate esoteric bugs. But new code-style warnings, such as whether your variables begin with capital letters, can easily fill up the formerly pristine Visual Studio Error List panel.
Of course, it's always best to address the more meaningful warnings as quickly as possible. But if there are situations where you need to keep the questionable code as it is, and you don't want to see the annoying warning message hanging around, Visual Studio offers a few different ways to suppress these messages, on scales from a single source line up to your entire project.
Consider, as an example, an asynchronous method that lacks an embedded await statement:
private async Task DoSomeWork()
{
// ----- This method lacks an await statement, and therefore
// generates C# compiler warning CS1998.
}
Such C# code will add warning CS1998 to your Visual Studio experience, as shown in Figure 1.
[Click on image for larger view.]
Figure 1. Missing Await Statement Warning
The Code column in the Error List panel identifies the specific warning identity. If you want to hide a particular warning code across your entire project, open the overall properties through the Project | Properties menu command, and when the properties appear, select the Build page. The Suppress Warnings box on that page accepts a semicolon-delimited list of codes. Entering CS1998 in that field (see Figure 2) prevents the compiler from reporting that warning project-wide.
[Click on image for larger view.]
Figure 2. Project-Level Warning Suppression
If your warning-suppression needs are a bit more targeted, use the C# language #pragma statement to hide messages within a code file or block of source. The "warning disable" version of the statement, when paired with a comma-delimited list of codes, disables those codes for the remainder of that file's processing:
#pragma warning disable CS1998
Leave off the list of codes to disable all warnings. If you want to reactivate the warnings later in the file, use the "warning restore" version of the statement instead. When used together, the two variations of the #pragma statement let you limit warning hiding to specific code lines:
#pragma warning disable CS1998 // Warning suppressed from here
private async Task DoSomeWork()
#pragma warning restore CS1998 // Warning recognized from here
{
}
If typing these statements is more than your fingers are willing to do, right-click on the warning message in the Error List panel and choose the Suppress | In Source command from the shortcut menu that appears. This action will surround the warning-laden line with the relevant #pragma statements.
Yet another way to disable warnings involves the SuppressMessage attribute, found in the System.Diagnostics.CodeAnalysis namespace. When applied to a method or other relevant code element, the attribute deactivates the indicated warning in a more object-centric manner:
// ----- Assumes: using System.Diagnostics.CodeAnalysis;
[SuppressMessage("Compiler", "CS1998")]
private async Task DoSomeWork()
{
}
I determined the first argument passed into the SuppressMessage attribute, "Compiler," by turning on the Category column in the Error List panel and copying the text that appears for that warning. There are other options included with the attribute that let you narrow down the focus to specific code features. Microsoft recommends that you use SuppressMessage sparingly. Whereas #pragma does its work early in the compilation process and then says goodbye, the suppression attribute adds content to your final assembly, leading to attribute bloat or worse.
The MSDN documentation (such as this for C#) lists many of the error and warning codes you might encounter, allowing you to be proactive in your warning-suppression activities. But because one major goal of programming is to fix problems instead of hiding them, it's probably best to act on individual messages as they pop up in the Error List panel. Let this be a warning to you.
About the Author
Tim Patrick has spent more than thirty years as a software architect and developer. His two most recent books on .NET development -- Start-to-Finish Visual C# 2015, and Start-to-Finish Visual Basic 2015 -- are available from http://owanipress.com. He blogs regularly at http://wellreadman.com.