Domanda

Da anni utilizzo la costante del compilatore DEBUG in VB.NET per scrivere messaggi sulla console.Ho anche utilizzato System.Diagnostics.Debug.Write in modo simile.Ho sempre capito che quando RELEASE veniva utilizzato come opzione di compilazione, tutte queste istruzioni venivano tralasciate dal compilatore, liberando il codice di produzione dal sovraccarico delle istruzioni di debug.Recentemente, lavorando con Silverlight 2 Beta 2, ho notato che Visual Studio si collegava effettivamente a una build RELEASE che stavo eseguendo da un sito Web pubblico e visualizzava istruzioni DEBUG che presumevo non fossero nemmeno compilate!Ora, la mia prima inclinazione è presumere che ci sia qualcosa di sbagliato nel mio ambiente, ma voglio anche chiedere a chiunque abbia una conoscenza approfondita di System.Diagnostics.Debug e dell'opzione di build DEBUG in generale cosa potrei fraintendere qui.

È stato utile?

Soluzione

Il metodo preferito è utilizzare effettivamente l'attributo condizionale per racchiudere le chiamate di debug, non utilizzare le direttive del compilatore.I #if possono diventare complicati e portare a strani problemi di compilazione.

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

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

Quando compili senza il flag DEBUG impostato, qualsiasi chiamata a WriteDebug verrà rimossa come si supponeva accadesse con Debug.Write().

Altri suggerimenti

Esaminare il Debug.Scrittura metodo.È contrassegnato con il

[Conditional("DEBUG")]

attributo.

La guida MSDN per Attributo condizionale stati:

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

Non importa se la configurazione della build ha un'etichetta di rilascio o debug, ciò che conta è se in essa è definito il simbolo DEBUG.

Quello che faccio è incapsulare la chiamata a Debug nella mia classe e aggiungere una direttiva di precompilazione

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

L'uso del simbolo del compilatore DEBUG, come hai detto, ometterà effettivamente il codice dall'assembly.

Credo che System.Diagnostics.Debug.Write verrà sempre restituito a un debugger collegato, anche se hai creato la modalità di rilascio.Secondo il Articolo MSDN:

Scrive informazioni sul debug nei listener di traccia nella raccolta Listeners.

Se non vuoi Qualunque output, dovrai racchiudere la tua chiamata a Debug.Write con la costante DEBUG come ha detto Juan:

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

Ho letto anche l'articolo e mi ha portato a credere che quando DEBUG non era definito, il ConditionalAttribute dichiarato sulle funzioni System.Debug avrebbe fatto sì che il compilatore tralasciasse completamente questo codice.Presumo che la stessa cosa sia vera per TRACE.Ovvero, le funzioni System.Diagnostics.Debug devono avere ConditionalAttributes per DEBUG e TRACE.Avevo torto in questa ipotesi.La classe Trace separata ha le stesse funzioni e queste definiscono ConditionalAttribute dipendente dalla costante TRACE.

Da System.Diagnostics.Debug:_ Sub di scrittura condivisa pubblica (_ Messaggio come stringa _)

Da System.Diagnostics.Trace:_ Public condiviso Sub WriteLine (_ Messaggio come String _)

Sembra quindi che la mia ipotesi originale fosse corretta, ovvero che le istruzioni System.Diagnostics.Debug (o system.Diagnostics.Trace) non siano effettivamente incluse nella compilazione come se fossero incluse 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 accedere alle "Opzioni di compilazione avanzate..." e assicurarsi che DEBUG non sia definito.

Siamo passati da .NET 1.1/VS2003 a .NET 3.5/VS2008 quindi penso che alcuni di questi funzionassero diversamente, ma forse è cambiato in 2.0/VS2005.

Per selezionare se desideri che le informazioni di debug vengano compilate o rimosse,

accedere alla scheda "Costruisci" nella finestra delle proprietà del progetto.

Scegli la configurazione giusta (attiva/rilascio/debug/all) e assicurati di controllare la "costante di debug" se si desidera le informazioni o deselezionale se non lo fai.

Applicare le modifiche e ricostruire

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

L'utilizzo di Release non rimuoverà sicuramente le istruzioni System.Diagnostics.Debug.Write.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top