Perché dovrei voler utilizzare la modalità debug del compilatore .NET?

Question

Ero curioso di sapere quali sono le differenze tra le modalità di debug e di rilascio del compilatore .NET e ho riscontrato queste domande su debug vs release in .NET e motivi per cui la versione si comporterà in modo diverso rispetto al debug . Fino ad ora non ho prestato molta attenzione a queste modalità di compilazione. Adesso lo farò.

La mia domanda è, supponendo che io stia usando un framework di test (NUnit) e TDD, incontrerei problemi se semplicemente compilassi sempre in modalità di rilascio?

Answer 1

Stai usando TDD. Scrivi il tuo test. Il test fallisce. Scrivi il codice per superare il test. Il codice ha esito negativo. Guardi il codice che hai scritto e non vedi alcuna ragione ovvia per cui non funziona. Ne pensi ancora o avvii il test nel debugger (usando TestDriven.Net) e passi attraverso il test? Forse non sono abbastanza intelligente da capire sempre perché il mio codice non funziona, ma di solito faccio quest'ultimo quando sono sconcertato.

Answer 2

La modalità debug disattiva molte delle ottimizzazioni. Ciò significa che quando si ottiene una traccia dello stack sarà più simile al codice originale.

Answer 3

Una differenza abbastanza significativa tra le configurazioni di debug e release è che le chiamate ai metodi contrassegnati con ConditionalAttribute vengono compilate solo se viene definito il simbolo associato. Pertanto, le chiamate ai metodi della classe Debug non vengono incluse se compilate utilizzando la configurazione della versione.

Ciò ti consente di festonare il tuo codice con asserzioni e codice che scarica le informazioni sulla console, e tuttavia avere la certezza che nessuna di queste spese generali apparirà nel tuo codice di spedizione.

Inoltre, edit-and-continue è uno strumento estremamente utile e si basa su metainformation che è stata omessa dalle build di rilascio.

Answer 4

Per il debug.

Come ha detto tvanfosson, anche se di solito non usi il debugger (so di no), a volte devi farlo.