Using Preprocessor Directives in C#


C# preprocessor directives are commands that are meant for the C# compiler. Using preprocessor directives you instruct the C# compiler to alter the compilation process in some way. For example you may instruct the C# compiler that a particular block of code be excluded from the compilation process. This article examines several C# preprocessor directives available, with an example of each.

#define and #undef

The #define preprocessor directive is used to define a symbol or a named token. You use this symbol later in your code with #if and #elif preprocessor directives. Consider the following line of code:

#define DEBUG

The above line of code defines a symbol - DEBUG. Although not mandatory, it is a common practice to define these symbols in upper case. You will find this line similar to a variable declaration but the difference is that it won't reserve any memory as such and can't hold any value. One important thing to remember is that all the #define directives you are using must appear at the top of the source code file. If you place them somewhere within the code you will get an error like this:

#define directives must appear at the top of the source code file or you'll get an error
#define directives must appear at the top of the source code file or you'll get an error

A symbol can be defined using #define or can also be passed via command line. The symbol thus defined can be undefined using #undef directive.

#undef DEBUG

Un-defining a symbol is like erasing it so that it doesn't exist for the later code.

#if, #else, #elif and #endif

The real use of symbols defined using #define is when they are coupled with #if and #elif directives. These preprocessor directives allow you to test whether a particular symbol has been defined. Based on the outcome of this test you can conditionally compile a piece of code. The following code shows how this is done.

#define DEBUG
    Console.WriteLine("You have defined DEBUG symbol");

In the above piece of code you first defined the DEBUG symbol. Somewhere later in your code you used #if directive to check whether DEBUG is defined. If so you output a message using Console.WriteLine(). If you run this application you will get an output as shown below:

You have defined DEBUG symbol
You have defined DEBUG symbol

If you remove the #define line or un-define the DEBUG symbol and then run the application, you won't see the message because the #if condition will evaluate to false.

You can test for multiple symbols using #elif as shown below:

    Console.WriteLine("You have defined STANDARD symbol");
    Console.WriteLine("You have defined PROFESSIONAL symbol");
    Console.WriteLine("You have defined ULTIMATE symbol");

You can also test multiple symbols in one #if using operators - ==, !=, && and ||. The following example shows how:

    Console.WriteLine("You have defined STANDARD and EVAL symbols");

#warning and #error

As you might have already guessed the #warning and #error preprocessor directives are used to emit warning and error messages respectively. The difference between #warning and #error is that #warning displays the warning message but doesn't halt the compilation process. However, #error halts the compilation in addition to displaying the error message. The following code shows how they are used:

#if EVAL && FULL
    #warning "You have defined EVAL as well as FULL"

The above code checks if symbol EVAL as well as FULL is defined, and if so a warning message is outputted. If you build the project and both of these symbols are defined you should get a warning as shown below:

You have defined EVAL as well as FULL warning
You have defined EVAL as well as FULL warning

If you would have used #error instead of #warning you would have got an error as shown below:

You have defined EVAL as well as FULL error
You have defined EVAL as well as FULL error

#region and #endregion

The #region and #endregion preprocessor directives come in handy when you are coding inside Visual Studio IDE. They allow you to define a region of code as one single block so that the entire block can be collapsed or expanded. Consider the following piece of code:

define a region of code as one single block
define a region of code as one single block

Here, you define a region, Public Properties, using the #region and #endregion directives. This region contains all the public properties defined by a class. The region can be expanded or collapsed using the - or + icon shown in the margin of the Visual Studio editor. If you are writing hundreds of lines of code in a single file then using #region and #endregion to divide the entire code into multiple logical regions can enhance your coding experience.


The #line preprocessor director is used to modify the line number and file name that appears in the compiler error messages. Consider, for example, the following code:

namespace CSPreProcessorDirectivesDemo
    class Program
        static void Main(string[] args)
            inta a = 100;

There is a syntax error at line no. 14 (inta a = 100) and the file name is Program.cs. If you try to compile this project you will get the following error.

Program.cs error
Program.cs error

Now, you can use #line directive to change the default line number and file name :

 #line 400 "MyFile.cs"
inta a = 100;

Here, the line number is set to 400 and file name is set to MyFile.cs. Compiling this code gives an error as shown below:

MyFile.cs error
MyFile.cs error

As you can see the line no. and file name displayed in the Error List is now picked from the #line directive. The #line directive is more useful in situations where source code is modified by some external tools or systems (ASP.NET is one such example).


#pragma preprocessor directive instructs the compiler about the compilation of the file under consideration. The instructions you used with #pragma must be supported by the compiler. As far as the C# compiler is concerned the following two instructions are supported:

#pragma warning 
#pragma checksum

Just as an example of using #pragma, consider the following line of code where warning 219 has been disabled:

#pragma warning disable 219

The warning number 219 is for "The variable is assigned but its value is never used". Once disabled the compiler will stop reporting the 219 warnings.


C# Preprocessor Directives are commands that are meant for the C# compiler. This article illustrated the use of #define, #undef, #if, #else, #elif, #endif, #warning, #error, #region, #endregion, #line and #pragma preprocessor directives.

Related Articles


  • Concise post reveal the indeniable information about chanel and also how it can certainly effect customers.

    Posted by emeseesip on 05/08/2013 12:27am

    By Far The Most Comprehensive gucci E-book You Ever Read Or Your Money Back [url=]グッチ キーケース[/url] Whoa, wonderful service. Your organization got to have a look at nike now when it is still in stock ! ! [url=]gucci キーケース[/url] nike aids every one of us by integrating a number of exceptional functions and functions. It is a unvaluable thing for every supporter of nike. [url=]グッチ ショルダーバッグ[/url] Unbiased guide provides 2 all new things concerning nike that no-one is speaking of. [url=]シャネル マトラッセ[/url] The reason absolutely no one is having a debate about nike and due to this fact know what you ought to complete today. [url=]chanel バッグ[/url] Recent queries about nike clarified and in addition the reason why you really need to read through each word of this e book. [url=]chanel バッグ[/url] The basic principles of nike it is possible to cash in on commencing today.[url=]ナイキ[/url] The simplest way to understand all sorts of things there is to find out surrounding adidas in nine very easy steps.

  • A practical double take on adidas

    Posted by Updatatweda on 05/06/2013 12:47am

    V [url=]アディダス スニーカー[/url] cvKde ZvoFta EygZpk DdwH [url=]adidas originals[/url] vcJbiFrt FmiIxqTgmA [url=]adidas superstar[/url] wv GdgWwo [url=]adidas jeremy scott[/url]AooEkw EzbLec

  • study

    Posted by sokchandarith on 04/19/2013 02:24am

    i want to study c# program with your web

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Moving from an on-premises environment to Office 365 does not remove the need to plan for disruptions or reduce the business risk requirements for protecting email services. If anything, some risks increase with a move to the cloud. Read how to ease the transition every business faces if considering or already migrating to cloud email. This white paper discusses: Setting expectations when migrating to Office 365 Understanding the implications of relying solely on Exchange Online security Necessary archiving …

  • Enterprises are increasingly looking to platform as a service (PaaS) to lower their costs and speed their time to market for new applications. Developing, deploying, and managing applications in the cloud eliminates the time and expense of managing a physical infrastructure to support them. PaaS offerings must deliver additional long-term benefits, such as a lower total cost of ownership (TCO), rapid scalability, and ease of integration, all while providing robust security and availability. This report …

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date