2008-08-26 20 views
18

Per anni ho utilizzato la costante del compilatore DEBUG in VB.NET per scrivere messaggi sulla console. Ho anche usato System.Diagnostics.Debug.Write in modo simile. Ho sempre compreso che quando RELEASE veniva usato come opzione di compilazione, tutte queste istruzioni venivano lasciate fuori dal compilatore, liberando il codice di produzione dal sovraccarico delle istruzioni di debug. Recentemente, quando ho lavorato con Silverlight 2 Beta 2, ho notato che Visual Studio è effettivamente collegato a un build RELEASE che stavo scaricando da un sito Web pubblico e ho visualizzato le dichiarazioni DEBUG che presumevo non erano nemmeno state compilate! Ora, la mia prima inclinazione è quella di supporre che ci sia qualcosa di sbagliato nel mio ambiente, ma voglio anche chiedere a chiunque abbia una conoscenza approfondita su System.Diagnostics.Debug e sull'opzione di build DEBUG in generale su cosa potrei essere frainteso qui.Compilatore .NET - DEBUG vs. RELEASE

risposta

21

Il metodo preferito è quello di realtà utilizzare l'attributo condizionale per avvolgere le chiamate di debug, non utilizzare le direttive del compilatore. #ifs può diventare complicato e può portare a problemi di build strani.

Un esempio di utilizzo di un attributo condizionale è la seguente (in C#, ma funziona in VB.NET troppo):

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

Quando si compila senza il flag di debug impostato, verranno rimossi qualsiasi chiamata a WriteDebug come era scontato stava accadendo con Debug.Write().

+0

Fantastico ... adoro imparare nuovi piccoli trucchi !! – BigBlondeViking

+1

Penso che l'uso di 'ConditionalAttribute' significa che il metodo fa ancora parte dell'assembly di rilascio effettivo, non è stato caricato. Quindi immagino che l'unico * vero * modo di rimuovere il codice di debug sia usare le direttive del compilatore? – James

-6

Nella mia esperienza la scelta tra Debug e Release in VB.NET non fa differenza. È possibile aggiungere azioni personalizzate a entrambe le configurazioni, ma per impostazione predefinita penso che siano uguali.

Utilizzando Release non verranno rimosse le istruzioni System.Diagnostics.Debug.Write.

+0

Essi non sono la stessa cosa; e la modalità di rilascio per impostazione predefinita rimuove effettivamente le chiamate a Debug.Write a causa del ConditionalAttribute applicato al metodo. –

1

quello che faccio è incapsulare la chiamata al debug nella mia classe e aggiungere una direttiva precompilatore

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

Utilizzando il simbolo DEBUG compilatore, come hai detto tu, in realtà omettere il codice dal gruppo.

Credo che System.Diagnostics.Debug.Write verrà sempre inviato a un debugger collegato, anche se è stata creata la modalità di rilascio. Per la MSDN article:

scrive le informazioni circa il debug per gli ascoltatori di analisi dell'insieme Listeners.

Se non si desidera alcun uscita, è necessario per avvolgere la chiamata al Debug.Write con la costante DEBUG come Juan ha detto:

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

Ho letto anche l'articolo, e mi ha portato a credere che quando DEBUG non era stato definito, che il ConditionalAttribute dichiarato nelle funzioni System.Debug avrebbe causato il compilatore di lasciare completamente questo codice. Presumo che la stessa cosa sia vera per TRACE. Cioè, le funzioni System.Diagnostics.Debug devono avere ConditionalAttributes per DEBUG e per TRACE. Ho sbagliato su questa ipotesi. La classe Trace separata ha le stesse funzioni e questi definiscono ConditionalAttribute dipendente dalla costante TRACE.

Da System.Diagnostics.Debug: _ pubblica condivisa Write Sub (_ messaggio As String _ )

Da System.Diagnostics.Traccia: _ Public Shared Sub WriteLine (_ messaggio As String _ )

Sembra allora che la mia ipotesi iniziale era corretta, che System.Diagnostics.Debug (o System.Diagnostics.Trace) dichiarazioni non sono in realtà inclusi nella compilation come se fossero inclusi nelle regioni #IF DEBUG (o #IF TRACE).

Ma ho anche imparato qui da voi ragazzi e verificato che la build RELEASE di per sé non si occupa di questo. Almeno con i progetti Silverlight, che sono ancora un po 'instabili, è necessario entrare nelle "Opzioni di compilazione avanzate ..." e accertarsi che DEBUG non sia definito.

Siamo passati da .NET 1.1/VS2003 a .NET 3.5/VS2008, quindi penso che un po 'di questo funzionasse diversamente, ma forse è cambiato in 2.0/VS2005.

5

Esaminare il metodo Debug.Write. È contrassegnato con lo

[Conditional("DEBUG")] 
attributo

.

L'aiuto MSDN per ConditionalAttribute stati:

Indica a compilatori che un metodo chiamata o di un attributo deve essere ignorato a meno che un condizionale simbolo compilazione specificato è definito.

Indipendentemente dal fatto che la configurazione di build abbia un'etichetta di rilascio o di debug non importa, ciò che importa è se il simbolo DEBUG è definito in esso.

1

per selezionare se si desidera che le informazioni di debug per essere compilato o da rimuovere,

inserire la scheda "Build" nella finestra delle proprietà del progetto.

scegliere la giusta configurazione (attivo/uscita/Debug/Tutti) e assicuratevi di verificate la "DEBUG costante" se si desidera che l'informazioni, o deselezionare se non lo fai.

Applica modifiche e ricostruire