#if preprocessor directive for directives other than DEBUG

Question

I know that I can use preprocessor directives to check for Debug/Release by doing this:

#if DEBUG
    //debug mode
#elif
    //release mode
#endif

but what about checking for other configurations, like Test. In VB you can do this:

#If CONFIG = "Release" Then
    'Release mode
#ElseIf CONFIG = "Test" Then
    'Test mode
#ElseIf CONFIG = "Debug" Then
    'Debug mode
#End If

So, my question is in C#, how can I check for Test mode? I have some code that I want to execute if I'm in Debug AND Test, but not in Release mode, so specifically, I need a way to check for not being in Release mode. In VB I would do this:

#If Not CONFIG = "Release" Then
    'Do something here for every configuration that is not Release
#End If

Answer 1

It's the same as for DEBUG, assuming that you've defined a build configuration that lists TEST in the "Conditional compilation symbols" text box (under project properties > Build tab; this is a space-delimited list).

For code that you only want to run in the TEST build configuration:

#if TEST
// ...
#endif

And for code you don't want to run in the TEST build configuration, you can either #else the above, or do this:

#if !TEST
// ...
#endif

Answer 2

There are a couple ways to handle your factorings. In my world, we used four primary techniques:

1. compiler flags (#if)
2. partial classes
3. separate implementations
4. Runtime decisions

So for example, we have build configurations for, C# with unmanaged code, C# with all managed code, C# for silverlight. In the C# unmanaged project we have a compile-time symbol UNMANAGED, for C# we have MANAGED and for the silverlight we have SILVERLIGHT. This lets me inject small tasks into the code and share the same files across all projects. No big deal.

For partial classes, we have separate .cs files for each project that have implementations of the fringe code. This gets used in the cases where we couldn't make this work by having an abstract class as the parent class with most of the implementation and then the fringe code in concrete classes for each target. This works well enough.

For separate implementations, we acknowledge that there is little that can be shared between the code bases and we're better off with separate code. This is not ideal, but so be it.

For runtime checks, it's exactly that. Rather than check for DEBUG in a #if, you use a runtime check for a setting to make that choice. Unless you've got heinously huge debug scaffolding, this is not a bad choice as it also lets you do field debugging (but you may have delivery constraints that prevent it).

Personally, I try to avoid the compiler flags. They make the code harder to read. Honestly, though, there are times where they make sense. We've had classes that wouldn't compile in silverlight just because of the class declaration (I think it was ObservableCollection that wasn't available) and we had to inherit from something else. Everything else worked fine.

Answer 3

Right click on the Project [Project name] name you want to use the custom precompiler directive.

Go to the properties item and then to the build tab.

then you need to add your custom directive there in the textbox. E.g i have added 'Local' as my custom directive see image below

Now you can can use the new compiler directive as shown below in your (in C#)

  #if **Local**
    //TODO:Add your c# code here
  #endif

Answer 4

Simple answer is

• Go to Project->[Project name] Properties->Build
• Set checked [] Define DEBUG

Now you can play with DEBUG predecessor directive like

#if DEBUG
...
#else
...
#endif