C# Preprocessor Directives

Control flow statements evaluate expressions at execution time. In contrast, the C# preprocessor is invoked during compilation. The preprocessor commands are directives to the C# compiler, specifying the sections of code to compile or identifying how to handle specific errors and warnings within the code. C# preprocessor commands can also provide directives to C# editors regarding the organization of code.

Language Contrast: C++—Preprocessing

Languages such as C and C++ use a preprocessor to perform actions on the code based on special tokens. Preprocessor directives generally tell the compiler how to compile the code in a file and do not participate in the compilation process itself. In contrast, the C# compiler handles “preprocessor” directives as part of the regular lexical analysis of the source code. As a result, C# does not support preprocessor macros beyond defining a constant. In fact, the term preprocessor is generally a misnomer in C#.

Each preprocessor directive begins with a hash symbol (#), and all preprocessor directives must appear on one line. A newline rather than a semicolon indicates the end of the directive.

A list of each preprocessor directive appears in Table 4.5.

Table 4.5: Preprocessor Directives

Statement or Expression

General Syntax Structure


#if directive

#if preprocessor-expression






#elif directive

#if preprocessor-expression1


#elif preprocessor-expression2








#else directive











#define directive

#define conditional-symbol


#undef directive

#undef conditional-symbol


#error directive

#error preproc-message

#error Buggy implementation

#warning directive

#warning preproc-message

#warning Needs code review

#pragma directive

#pragma warning

#pragma warning disable 1030

#line directive

#line org-line new-line

#line 467



#line default

#line default

#region directive

#region pre-proc-message



#region Methods



#nullable directive

#nullable enable | disable | restore

#nullable enable

..string? text = null;

#nullable restore

Excluding and Including Code (#if, #elif, #else, #endif)

Perhaps the most common use of preprocessor directives is in controlling when and how code is included. For example, to write code that could be compiled by both C# 2.0 and later compilers and the prior version 1.0 compilers, you would use a preprocessor directive to exclude C# 2.0–specific code when compiling with a version 1.0 compiler. You can see this in the tic-tac-toe example and in Listing 4.56.

Listing 4.56: Excluding C# 2.0 Code from a C# 1.x Compiler

In this case, you call the System.Console.Clear() method. Using the #if and #endif preprocessor directives, this line of code is compiled only if the preprocessor symbol CSHARP2PLUS is defined.

Another use of preprocessor directives would be to handle differences among platforms, such as surrounding Windows- and Linux-specific APIs with WINDOWS and LINUX #if directives. Developers often use these directives in place of multiline comments (/*...*/) because they are easier to remove by defining the appropriate symbol or via a search and replace.

A final common use of the directives is for debugging. If you surround code with an #if DEBUG, you will remove the code from a release build on most IDEs. The IDEs define the DEBUG symbol by default in a debug compile and RELEASE by default for release builds.

To handle an else-if condition, you can use the #elif directive within the #if directive instead of creating two entirely separate #if blocks, as shown in Listing 4.57.

Listing 4.57: Using #if, #elif, and #endif Directives
// ...
// ...
Defining Preprocessor Symbols (#define, #undef)

You can define a preprocessor symbol in two ways. The first is with the #define directive, as shown in Listing 4.58.

Listing 4.58: A #define Example

The second method uses the define command line. Output 4.27 demonstrates this with Dotnet command-line interface.

Output 4.27
>dotnet build -p:DefineConstants=CSHARP2PLUS

To add multiple definitions, separate them with a semicolon. The advantage of the define compiler option is that no source code changes are required, so you may use the same source files to produce two different binaries.

To undefine a symbol, you use the #undef directive in the same way you use #define.

Emitting Errors and Warnings (#error, #warning)

Sometimes you may want to flag a potential problem with your code. You do this by inserting #error and #warning directives to emit an error or a warning, respectively. Listing 4.59 uses the tic-tac-toe example to warn that the code does not yet prevent players from entering the same move multiple times. The results of Listing 4.59 appear in Output 4.28.

Listing 4.59: Defining a Warning with #warning
#warning "Same move allowed multiple times."
Output 4.28
Performing main compilation...
...\tictactoe.cs(471,16): warning CS1030: #warning: '"Same move allowed multiple times."'
Build complete -- 0 errors, 1 warnings

By including the #warning directive, you ensure that the compiler will report a warning, as shown in Output 4.28. This particular warning is a way of flagging the fact that there is a potential enhancement or bug within the code. It could be a simple way of reminding the developer of a pending task.

Turning Off Warning Messages (#pragma)

Warnings are helpful because they point to code that could potentially be troublesome. However, sometimes it is preferred to turn off specific warnings explicitly because they can be ignored legitimately. C# provides the preprocessor #pragma directive for just this purpose (see Listing 4.60).6

Listing 4.60: Using the Preprocessor #pragma Directive to Disable the #warning Directive
#pragma warning disable CS1030

To reenable the warning, #pragma supports the restore option following the warning, as shown in Listing 4.61.

Listing 4.61: Using the Preprocessor #pragma Directive to Restore a Warning
#pragma warning restore CS1030

In combination, these two directives can surround a particular block of code where the warning is explicitly determined to be irrelevant.

Perhaps one of the most common warnings to disable is CS1591. This warning appears when you elect to generate XML documentation using the /doc compiler option, but you neglect to document all of the public items within your program.

Code warnings occur frequently throughout this book because listings often are incomplete—that is, we are showing initial code snippets that aren’t fully developed. To suppress the warnings, since they are not relevant in an example code scenario, we add #pragma directives to the file. Table 4.6 provides an example of some of the warnings that are disabled within various code snippets in Chapter 4.

Table 4.6: Sample Warnings




Variable is declared but never used


Variable is assigned but its value is never used


Unnecessary assignment of a value

Such #pragma disable-warning directives are often embedded within the book’s source code to address warnings that crop up because the example code is not fully developed but rather intended for the purpose of elucidation.

Note that C# warning numbers are prefixed with the letters CS in the compiler output, a prefix that is optional in the #pragma directive. Such a number corresponds to the warning error number emitted by the compiler when there is no preprocessor command. However, there are other prefixes like “IDE” that are part of the identity. The IDE0059 message is an example. Code analyzers generate IDE-prefixed warnings to suggest code improvements, and removing the prefix will no longer refer to the same warning.

nowarn:<warn list> Option

In addition to the #pragma directive, C# compilers generally support the nowarn=<warn list> option. This achieves the same result as #pragma, except that instead of adding it to the source code, you can insert the command as a compiler option. The nowarn option affects the entire compilation, whereas the #pragma option affects only the file in which it appears. To turn off the CS0219 warning, for example, you would use the command line as shown in Output 4.29.

Output 4.29
> dotnet build /p:NoWarn="0219"
Specifying Line Numbers (#line)

The #line directive controls on which line number the C# compiler reports an error or warning. It is used predominantly by utilities and designers that emit C# code. In Listing 4.62, the actual line numbers within the file appear on the left.

Listing 4.62: The #line Preprocessor Directive
#line 113 "TicTacToe.cs"
#warning "Same move allowed multiple times."
#line default

Including the #line directive causes the compiler to report the warning found on line 125 as though it were on line 113, as shown in the compiler error message in Output 4.30.

Output 4.30
Performing main compilation...
...\tictactoe.cs(113,18): warning CS1030: #warning: '"Same move allowed multiple times."'
Build complete -- 0 errors, 1 warnings

Following the #line directive with default reverses the effect of all prior #line directives and instructs the compiler to report true line numbers rather than the ones designated by previous uses of the #line directive.

Hints for Visual Editors (#region, #endregion)

C# contains two preprocessor directives, #region and #endregion, that are useful only within the context of visual code editors. Code editors, such as Microsoft Visual Studio, can search through source code and find these directives to provide editor features when writing code. C# allows you to declare a region of code using the #region directive. You must pair the #region directive with a matching #endregion directive, both of which may optionally include a descriptive string following the directive. In addition, you may nest regions within one another.

Listing 4.63 shows the tic-tac-toe program as an example.

Listing 4.63: #region and #endregion Preprocessor Directives
// ...
#region Display Tic-tac-toe Board
// Display the current board
border = 0;   //  set the first border (border[0] = "|")
// Display the top line of dashes
// ("\n---+---+---\n")
foreach(char cell in cells)
    // Write out a cell value and the border that comes after it
    Console.Write($" { cell } { borders[border] }");
    // Increment to the next border
    // Reset border to 0 if it is 3
    if(border == 3)
        border = 0;
#endregion Display Tic-tac-toe Board
// ...

These preprocessor directives are used, for example, with Microsoft Visual Studio. Visual Studio examines the code and provides a tree control to open and collapse the code (on the left-hand side of the code editor window) that matches the region demarcated by the #region directives (see Figure 4.5).

Figure 4.5: Collapsed region in Microsoft Visual Studio .NET
Activating Nullable Reference Types (#nullable)

As described in Chapter 3, the #nullable preprocessor directive activates (or deactivates) support for nullable reference types. #nullable enable turns on the nullable reference type feature, and #nullable disable turns it off. In addition, #nullable restore returns the nullable reference type feature back to the default value identified in the project file’s Nullable element.


6. Introduced in C# 2.0.
{{ snackbarMessage }}