John,
There is no benefit of using [Conditional("DEBUG")] to the called method
itself per se, the benefit is for the calling methods. You can leave all the
calls to a [Conditional("DEBUG")] method and the compiler will quietly
change them into no ops on release builds, or the actual method calls in
debug builds.
What I will do is use both [Conditional("DEBUG")] & #if DEBUG on internal
methods, which will remove the calls & the code for that method from the
assembly, for public methods in class libraries I will use only
[Conditional("DEBUG")] as assemblies compiled against the class library may
or may not have defined DEBUG.
For an example of the use of [Conditional("DEBUG")], see all the methods in
the System.Diagnostics.Debug & System.Diagnostics.Trace classes. :-)
For more details see:
http://msdn.microsoft.com/library/de...TraceDebug.asp http://msdn.microsoft.com/msdnmag/is...r/default.aspx
Hope this helps
Jay
"John Smith" <someone@microsoft.com> wrote in message
news:5yNUb.78971$5K1.3850989@twister.southeast.rr. com...[color=blue]
> After reading C# documentation the Conditional attribute seemed the way to
> go, but after inspecting the IL it seems those methods are still there and[/color]
I[color=blue]
> imagine the CLR removes them. Using #if DEBUG means the code does not even
> reach the IL when compiling in release mode.
>
> Is there any benefit to using the Conditional Attribute? Am I right in
> thinking there will small performance overhead using[/color]
[Conditional("DEBUG")][color=blue]
> over #if DEBUG.
>
>[/color]