Recently, Phil Haack made a post about Conditional Compilation Constants and ASP.Net. Typically, one would use a compiler directive to "inject" a bit of code into the assembly for debugging purposes when they are developing their software, but want to be sure that the injected debug code does not end up into the final product. 

Normally, you would use compiler directives to accomplish this and not even worry about it.  However, in the world of ASP.Net development it just doesn't seem to work like that as Phil documented rather well.  Most ASP.Net developers just accept this as true to the fact that the VS.Net team treat us as the red-headed step children that we are and move on with manually adding and removing code like we've always had to do since the days of classic ASP :)

However, there is a work around.. ugly, but a work around non-the-less...

You can do pseudo debugging checks in web site projects (vs web application projects) by checking the httpcontext.  For example, for one of our websites, we've developed some custom http modules that we turn on in our model office / production environment, but off for our dev environments.

In our dev environments, we have debugging="true" in web.config and in the others, we of course have debugging="false".

So, when you want to check for debugging being enabled, then instead of wrapping up your code like this:

#if DEBUG
   ... some code here
#else
   ... some other code here
#end if

You would do something like this:

  if (!HttpContext.Current.IsDebuggingEnabled)
  {
    // Production mode code here
  }
  else
  {
    // Debugging Code Here
  }

The obvious disadvantage of this method vs using compiler pre-directives is that all of your "debug" code is compiled into the final assembly.  So weigh your options and go from there.