In an application built with Visual Studio 2013 I have the TRACE constant unchecked:
From my understanding, this is supposed to mean that any call made by a System.Diagnostics.TraceSource object will not be included in the compiled code per MSDN
For example, when the Trace constant is undefined and the project is built, the call to TraceInformation() below will not appear in the compiled code:
TraceSource ts = new TraceSource("MyTraceSource");
ts.TraceInformation("This will not be included in compiled code.");
I've been doing this for years with never a problem. Today, in a hybrid Asp.Net webforms/mvc application, I added tracing to a public static class, in property getters and setters and in functions, like so:
public static class MyClass
{
private static TraceSource ts = new TraceSource("MySource");
private static string _s;
public static string MyString
{
get
{
ts.TraceInformation("I don't expect to see this in compiled code.")
return _s;
}
}
...and was shocked to discover the trace calls in the compiled code. Why is Visual Studio including these trace calls in the compiled code?
Oddly enough, the problem is occurring just in this one class. The application has hundreds of trace calls (in code behind pages, in referenced projects, and etc.), but just in this one class the trace calls make it into the compiled code.
I initially thought this had something to do with it being a public static class or having static property getters and setters, but building a test project quickly showed that is not it.
I looked for the phrase "#TRACE" in the solution, but it not defined anywhere.
Even if I include these magic words at the top of code module:
#undef TRACE
Visual Studio still includes the trace calls in the compiled code.
This is an old, sprawling application. Is there some setting hidden somewhere that is telling Visual Studio 2013 to sometimes include trace calls in the compiled code?
