Qual è un buon approccio per aggiungere il codice di debug alla tua applicazione quando vuoi maggiori informazioni su cosa sta andando male?

Per il lato VCS:

1. Nel caso di Git devi avere due rami separati per le versioni pulite e di debug. Il lavoro ordinario avviene in master, debugging - in debug branch (o bugfix branch, ramificato da debug ) con informazioni di debug aggiunte.

2. Durante il ciclo di vita si uniscono in modo permanente le modifiche da master a debug , quindi - hanno due versioni, che differiscono solo per l'importo delle informazioni di debug. Dopo la ricerca del bug ti ritrovi indietro (da debug a master) solo la parte rilevante delle modifiche dal ramo.

BTW: Mercurial con MQ richiede meno frizioni attorno alla fusione delle diramazioni e usa solo un ramo principale, mentre consente di usare inserimenti del codice di debug

IMHO il modo migliore è la prevenzione, registrando tutte le informazioni necessarie all'interno dei messaggi di eccezione. Nel caso ideale, questo - insieme ai normali messaggi di log - sarebbe sufficiente per riprodurre il bug nel tuo ambiente di sviluppo. Ma anche nel caso meno che ideale, questo dovrebbe aiutarti a focalizzare meglio le tue indagini, richiedendo meno log di debug aggiuntivi per determinare l'esatta causa alla radice.

In quest'ultimo caso, come suggerito anche da altri, è possibile ridurre al minimo le interruzioni e le penalità legate alle prestazioni causate da messaggi di registro superflui impostando attentamente i livelli dei messaggi di registro e applicando la soglia di livello di registro appropriata in produzione. Non ho familiarità con i framework di registrazione C # ma in Java, tutti i framework di registrazione mainstream lo consentono, quindi sono abbastanza sicuro che tu possa trovare soluzioni simili anche nel mondo .Net.

Potresti avere una serie di messaggi tramite il livello di registrazione di debug (), info (), trace (). Qualcosa come nlog ti permetterà di farlo. Durante la produzione, puoi impostare il livello di registrazione e qualsiasi cosa sotto ciò che vuoi verrà scartata.

Modifica: suggerirei di includere nlog sotto una classe e di usare quella classe. In questo modo, se decidi di cambiare logger, è necessario modificare solo una classe.

Hai esaminato un framework di registrazione come log4net (ce ne sono anche altri, ma questo sembra essere il più popolare per. NET)? Ho usato l'equivalente Java, Log4J e ha la capacità di registrare messaggi a diversi livelli, come Info, Avvisa, Errore, Debug, Fatale. È possibile modificare il livello di registrazione dell'applicazione tramite la configurazione piuttosto che crearla. In tal modo, è possibile eseguire normalmente l'applicazione in produzione a livello di log "Fatal", ma sulla workstation, eseguire la registrazione su "Avvisa" o "Debug" e nessuna ricompilazione è necessaria!

L'unica parte difficile è capire a che livello dovrebbe essere un messaggio di registrazione.

Se sei preoccupato solo che il codice di debug crei grandi file di debug, puoi ancora averlo in produzione ma disabilitato (magari con una bandiera globale)

così quando vuoi che l'utente lo accenda, fallo cambiare un file di configurazione o passa un argomento all'eseguibile.

Nota: presumo che tu abbia già un codice di debug, se non penso che la risposta di Sardathrion sia la migliore .

Suggerirei di non avere versioni di produzione con debug integrato e altre senza. Costruisci il tuo debug nel codice di produzione e:

• scegli un modo per accenderlo e spegnerlo all'avvio dai vari suggerimenti sopra.
• attiva la funzione su richiesta.

Potresti forse fare quest'ultimo usando le griglie di proprietà e il riflesso per ispezionare i tuoi oggetti in fase di esecuzione, attivati da un tasto di scelta rapida.

Se sei preoccupato di emettere file di debug di grandi dimensioni, puoi scrivere tutto in memoria e inviarlo a file o schermo, se necessario (ad es. al comando dell'utente, su Eccezione o se è attivo un interruttore per quella particolare caratteristica ecc ...)

Il debugging finale è che spesso è possibile risparmiare un sacco di tempo semplicemente affermando se le condizioni sono vere o false all'interno dei propri metodi e proprietà, invece di scrivere in un file di debug che dovrete leggere fisicamente determinare quale fosse la condizione.