C# Snippet - Using the Conditional Attribute [Beginner]

You probably know about methods like Debug.WriteLine and Debug.Assert. A big part of their use is that they only do stuff if you are running a application compiled in Debug mode. If you are running in release mode, however, its like those calls in your code don't even exist - this way you can feel free to put helpful debug messages and checks in your code without worrying about the release version of the application being affected. Have you ever wondered how this is done?

Well, what happens in the end is that those calls really don't exist in a release compiled version of an application - they are literally ripped out of the code. But there is no magic going on here, and nothing that is specially restricted to Microsoft's own code - its actually just a plain old method attribute, one that we can use in our own code if we wanted to.

Heres the method signature for Debug.WriteLine:

[ConditionalAttribute("DEBUG")]
public static void WriteLine(string message)

That ConditionalAttribute tag on the method signature means that the method call only really exists if the code is compiled in Debug mode (i.e., the symbol DEBUG is defined). For instance, take a look at the following (very simple) chunk of code:

namespace ConditionalAttributeTest
{
  class Program
  {
    static void Main(string[] args)
    {
      Debug.WriteLine("I'm a message!");
    }
  }
}

When this code is compiled in debug mode, if you take a look at the MSIL (Microsoft Intermediate Language, the language C# is compiled into) inside the executable, you will see the following:

.class private auto ansi beforefieldinit Program
    extends [mscorlib]System.Object
{
  .method public hidebysig specialname rtspecialname 
      instance void .ctor() cil managed
  {
    .maxstack 8
    L_0000: ldarg.0 
    L_0001: call instance void [mscorlib]System.Object::.ctor()
    L_0006: ret 
  }

  .method private hidebysig static void Main(string[] args) cil managed
  {
    .entrypoint
    .maxstack 8
    L_0000: nop 
    L_0001: ldstr "I\'m a message!"
    L_0006: call void [System]System.Diagnostics.Debug::WriteLine(string)
    L_000b: nop 
    L_000c: ret 
  }
}

Now in all that mess of MSIL, you can probably see the call to Debug.WriteLine that prints out that string. But if you compile the exact same code in release mode, and look at the MSIL, you see the following:

.class private auto ansi beforefieldinit Program
    extends [mscorlib]System.Object
{
  .method public hidebysig specialname rtspecialname 
      instance void .ctor() cil managed
  {
    .maxstack 8
    L_0000: ldarg.0 
    L_0001: call instance void [mscorlib]System.Object::.ctor()
    L_0006: ret 
  }

  .method private hidebysig static void Main(string[] args) cil managed
  {
    .entrypoint
    .maxstack 8
    L_0000: ret 
  }
}

Now there is no trace of the Debug.WriteLine call at all - even the string we were going to print out, it is completely gone.

So how do we use this attribute? Well it's as simple as what was done for Debug.WriteLine - just drop the attribute on top of the method that you want to conditionally compile out. It doesn't have to be the DEBUG symbol, either - it can be for symbols you have defined yourself. For instance, say you wanted to gather some performance data when the symbol TIMERS is defined. You could have some code like the following:

public static class TimerCalls
{
  private static Dictionary<string, Stopwatch> _Stopwatches
    = new Dictionary<string, Stopwatch>();

  [ConditionalAttribute("TIMERS")]
  public static void StartStopwatch(string key)
  {
    if(_Stopwatches.ContainsKey(key))
    { return; } //Stopwatch already running

    _Stopwatches.Add(key, Stopwatch.StartNew()); 
  }

  [ConditionalAttribute("TIMERS")]
  public static void StopStopwatch(string key)
  {
    if(!_Stopwatches.ContainsKey(key))
    { return; } //No such stopwatch currently
    var watch = _Stopwatches[key];
    watch.Stop();
    _Stopwatches.Remove(key);
    Console.WriteLine(String.Format("Timer: {0}, {1}ms", key,
        watch.Elapsed.TotalMilliseconds));
  }
}

The use of the conditional attribute there means that those two calls - StartStopwatch and StopStopwatch - only exist when the TIMERS symbol is defined. So if you take the following code and compile and run it:

#define TIMERS

class Program
{
  static void Main(string[] args)
  {
    TimerCalls.StartStopwatch("SumNumbers");
    int total = 0;
    for (int i = 0; i < 10000; i++)
    { total += i; }
    Console.WriteLine(total);
    TimerCalls.StopStopwatch("SumNumbers");

    Console.Read();
  }
}

You get this output:

49995000
Timer: SumNumbers, 2.7013ms 

But if you take out that #define TIMERS statement at the top, you get this output:

49995000

Now I know this could technically all be done with#If statements, but using #If statements everywhere starts to really clutter code. In my opinion it makes code harder to read - plus you end up having to if-def out every single instance of whatever you are conditionally compiling. Using the ConditionalAttribute guarantees that every call is automatically stripped out - no worries that you missed one, or someone else added one in and forgot to add the if-def.

Well, that's it for ConditionalAttribute, another one of those obscure but handy features of C# (and the other .NET languages). The Visual Studio solution with the TimerCalls class is below, if you want to grab it and play around. 

Conditional Attribute Test Zip (6kb)

Source Files:

• ConditionalAttributeTest.zip