For years I have been using the DEBUG compiler constant in VB.NET to write messages to the console. I've also been using System.Diagnostics.Debug.Write in similar fashion. It was always my understanding that when RELEASE was used as the build option, that all of these statements were left out by the compiler, freeing your production code of the overhead of debug statements. Recently when working with Silverlight 2 Beta 2, I noticed that Visual Studio actually attached to a RELEASE build that I was running off of a public website and displayed DEBUG statements which I assumed weren't even compiled! Now, my first inclination is to assume that that there is something wrong with my environment, but I also want to ask anyone with deep knowledge on System.Diagnostics.Debug and the DEBUG build option in general what I may be misunderstanding here.
In my experience choosing between Debug and Release in VB.NET makes no difference. You may add custom actions to both configuration, but by default I think they are the same.
Using Release will certainly not remove the System.Diagnostics.Debug.Write statements.
What I do is encapsulate the call to Debug in my own class and add a precompiler directive
public void Debug(string s)
{
#if DEBUG
System.Diagnostics.Debug(...);
#endif
}
Using the DEBUG compiler symbol will, like you said, actually omit the code from the assembly.
I believe that System.Diagnostics.Debug.Write will always output to an attached debugger, even if you've built in Release mode. Per the MSDN article:
Writes information about the debug to the trace listeners in the Listeners collection.
If you don't want any output, you'll need to wrap your call to Debug.Write with the DEBUG constant like Juan said:
#if DEBUG
System.Diagnostics.Debug.Write(...);
#endif
The preferred method is to actually use the conditional attribute to wrap your debug calls, not use the compiler directives. #ifs can get tricky and can lead to weird build problems.
An example of using a conditional attribute is as follows (in C#, but works in VB.NET too):
[ Conditional("Debug") ]
private void WriteDebug(string debugString)
{
// do stuff
}
When you compile without the DEBUG flag set, any call to WriteDebug will be removed as was assumed was happening with Debug.Write().
I read the article too, and it led me to believe that when DEBUG was not defined, that the ConditionalAttribute declared on System.Debug functions would cause the compiler to leave out this code completely. I assume the same thing to be true for TRACE. That is, the System.Diagnostics.Debug functions must have ConditionalAttributes for DEBUG and for TRACE. I was wrong in that assumption. The separate Trace class has the same functions, and these define ConditionalAttribute dependent on the TRACE constant.
From System.Diagnostics.Debug: _ Public Shared Sub Write ( _ message As String _ )
From System.Diagnostics.Trace: _ Public Shared Sub WriteLine ( _ message As String _ )
It seems then that my original assumption was correct, that System.Diagnostics.Debug (or system.Diagnostics.Trace) statements are actually not included in compilation as if they were included in #IF DEBUG (or #IF TRACE) regions.
But I've also learned here from you guys, and verified, that the RELEASE build does not in itself take care of this. At least with Silverlight projects, which are still a little flaky, you need to get into the "Advanced Compile Options..." and make sure DEBUG is not defined.
We jumped from .NET 1.1/VS2003 to .NET 3.5/VS2008 so I think some of this used to work differently, but perhaps it changed in 2.0/VS2005.
Examine the Debug.Write method. It is marked with the
[Conditional("DEBUG")]
attribute.
The MSDN help for ConditionalAttribute states:
Indicates to compilers that a method call or attribute should be ignored unless a specified conditional compilation symbol is defined.
Whether the build configuration has a label of release or debug doesn't matter, what matters is whether the DEBUG symbol is defined in it.
To select whether you want the debug information to be compiled or to be removed,
enter the "Build" tab in the project's properties window.
Choose the right configuration (Active/Release/Debug/All) and make sure you check the "DEBUG Constant" if you want the info, or uncheck it if you don't.
Apply changes and rebuild