2008-08-26 23 views
18

Durante años he estado usando la constante del compilador DEBUG en VB.NET para escribir mensajes en la consola. También he estado usando System.Diagnostics.Debug.Write de manera similar. Siempre entendí que cuando RELEASE se usó como opción de compilación, todas esas declaraciones quedaron fuera del compilador, liberando su código de producción de la sobrecarga de las instrucciones de depuración. Recientemente, cuando trabajé con Silverlight 2 Beta 2, noté que Visual Studio en realidad estaba conectado a una compilación RELEASE que estaba ejecutando fuera de un sitio web público y que mostraba declaraciones DEBUG que supuse que ni siquiera estaban compiladas. Ahora, mi primera inclinación es suponer que hay algo mal en mi entorno, pero también quiero preguntar a cualquier persona que tenga un conocimiento profundo sobre System.Diagnostics.Debug y la opción de compilación DEBUG en general lo que podría malinterpretar aquí.Compilador .NET - DEBUG vs. RELEASE

Respuesta

21

El método preferido es en realidad use el atributo condicional para envolver sus llamadas de depuración, no use las directivas del compilador. #ifs puede ser complicado y puede llevar a problemas de construcción extraños.

Un ejemplo del uso de un atributo condicional es el siguiente (en C#, pero trabaja en VB.NET también):

[ Conditional("Debug") ] 
private void WriteDebug(string debugString) 
{ 
    // do stuff 
} 

Cuando se compila sin el conjunto indicador de depuración, se eliminará cualquier llamada a WriteDebug como se suponía que estaba pasando con Debug.Write().

+0

Impresionante ... me encanta aprender nuevos pequeños trucos !! – BigBlondeViking

+1

Creo que el uso de 'ConditionalAttribute' significa que el método todavía forma parte del ensamblaje de lanzamiento real, simplemente no está cargado. Entonces, ¿me imagino que la única forma * verdadera * de eliminar el código de depuración es usar las directivas del compilador? – James

-6

En mi experiencia, elegir entre depurar y liberar en VB.NET no hace diferencia. Puede agregar acciones personalizadas a ambas configuraciones, pero de manera predeterminada, creo que son las mismas.

El uso de Release no eliminará las instrucciones System.Diagnostics.Debug.Write.

+0

No son lo mismo; y el modo Liberar de forma predeterminada elimina realmente las llamadas a Debug.Write debido a la ConditionalAttribute aplicada al método. –

1

Lo que hago es encapsular la llamada a la depuración en mi propia clase y añadir una directiva precompilador

public void Debug(string s) 
{ 
#if DEBUG 
    System.Diagnostics.Debug(...); 
#endif 
} 
1

Usando el símbolo DEBUG compilador, como usted ha dicho, en realidad omitir el código de la asamblea.

Creo que System.Diagnostics.Debug.Write siempre dará salida a un depurador adjunto, incluso si ha creado en modo Release. Por el MSDN article:

Escribe información sobre la depuración para los detectores de seguimiento en la colección Listeners.

Si no desea ninguna salida , que necesita para envolver su llamada a Debug.Write con la constante DEBUG como Juan dijo:

#if DEBUG 
    System.Diagnostics.Debug.Write(...); 
#endif 
1

También leí el artículo, y me llevó a creer que cuando DEBUG no estaba definido, que la función ConditionalAttribute declarada en System.Debug provocaría que el compilador omita este código por completo. Supongo que lo mismo es cierto para TRACE. Es decir, las funciones System.Diagnostics.Debug deben tener AtributoCondicional para DEBUG y para TRACE. Estaba equivocado en esa suposición. La clase Trace separada tiene las mismas funciones, y éstas definen ConditionalAttribute dependiendo de la constante TRACE.

De System.Diagnostics.Debug: _ pública compartida de escritura Sub (_ mensaje As String _ )

De System.Diagnostics.Traza: _ Pública Shared Sub WriteLine (_ mensaje As String _ )

Parece entonces que mi suposición inicial era correcta, que System.Diagnostics.Debug (o System.Diagnostics.Trace) declaraciones no son en realidad incluidos en la compilación como si estuvieran incluidos en las regiones #IF DEBUG (o #IF TRACE).

Pero también he aprendido aquí de ustedes y he verificado que la compilación RELEASE no se ocupa en sí misma de esto. Al menos con los proyectos de Silverlight, que todavía son un poco escamosos, debe ingresar a las "Opciones de compilación avanzada ..." y asegurarse de que DEBUG no esté definido.

Pasamos de .NET 1.1/VS2003 a .NET 3.5/VS2008, así que creo que algo de esto solía funcionar de manera diferente, pero quizás cambió en 2.0/VS2005.

5

Examine el método Debug.Write. Está marcado con el

[Conditional("DEBUG")] 

atributo.

La ayuda de MSDN para ConditionalAttribute estados:

Indica a los compiladores que un método llamada o atributo debe ser ignorada a menos que un símbolo condicional compilación especificada se define.

No importa si la configuración de compilación tiene una etiqueta de versión o depuración, lo que importa es si el símbolo DEPURAR está definido en ella.

1

para seleccionar si desea que la información de depuración para ser compilado o para ser retirado,

entrar en la pestaña "Build" en la ventana de propiedades del proyecto.

elegir la configuración correcta (activa/Liberación/Depuración/All) y asegúrese de que comprueba la "DEBUG constante" si desea que la información, o la desactiva si no lo hace.

Aplicar cambios y reconstruir

Cuestiones relacionadas