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.

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.

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.

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.

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

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

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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

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.

________________________________________