Vantaggi e svantaggi di includere i file PDB con l'applicazione di rilascio

Question

Ho un'applicazione VB.net. Attualmente la versione di rilascio dell'applicazione viene prodotta senza un file PDB. Questo mi dà registri degli errori privi di dettagli utili come i numeri di riga. Sto cercando di includere i file PDB con build futuri, ma mi piacerebbe sapere quali sono i vantaggi e gli svantaggi di questo (prestazioni saggio, dimensioni saggio, sicurezza del codice saggio)

Answer 1

Quando si distribuiscono i simboli di debug per la tua applicazione, diventa davvero facile per qualcuno di venire avanti e decodificare il tuo lavoro, che alcune persone trovano indesiderabile. Allo stesso modo, è necessario distribuire più file e il progetto distribuibile diventa più grande. I file PDB non causano rallentamenti nell'app, poiché la spedizione di un PDB non sempre impedisce di perseguire ottimizzazioni (devi solo fare attenzione: le impostazioni predefinite del progetto "Debug" tendono a non ottimizzare i tuoi output quando generare PDB).

Answer 2

so che sto andando ottenere picchiato per questo, ma ...

Sono d'accordo con Dave Markle, ma mi piacerebbe aggiungere che un vantaggio di pubblicare i file PDB è, come hai detto , MOLTO carino per il debug.

Detto questo, non vendo software e il codice che scrivo è tutto per uso interno nella nostra azienda. In questo contesto, non vedo un problema con la messa in produzione del codice di debug, insieme ai file PDB. Non ho mai visto un successo in termini di prestazioni e, in tutta onestà, raramente i nostri utenti ci forniscono le informazioni corrette se riscontrano eccezioni non gestite. Certo, proviamo a gestire le eccezioni correttamente, ma come sai, gli errori accadranno. La nostra strategia consiste nell'aggiungere un gestore di eccezioni globale a TUTTI i progetti e registrare tali eventi nel database. Questi errori contengono i numeri di riga perché includiamo i file di debug e, di conseguenza, siamo in grado di identificare e reagire rapidamente al codice errato, correggerlo e ottenere più applicazioni prive di bug. Per me (e per i nostri utenti) questo è un vantaggio enorme di cui non vorrei fare a meno.

Quindi, se siete in una situazione simile, dico dimenticare la posizione ufficiale (in questo caso) e andare avanti e pubblicare i file PDB con UNA importante avvertimento.

Assicurarsi che qualsiasi applicazione Web distribuita con i file PDB sia completamente sicura che TUTTE le eccezioni siano gestite correttamente e che non si espongano inavvertitamente righe di codice in una pagina di errore Asp.NET standard.

Answer 3

Trovo utile avere anche le informazioni di debug create per la versione di rilascio - aiuta a catturare i bug. Non fa rallentare il programma. Ma non dovresti spedire il file PDB con la tua applicazione, se non vuoi che altri siano in grado di eseguirne il reverse-engineering più facilmente. Dagli solo ai tester.

Answer 4

Creare pdbs per la build di rilascio, ma non spedirli. Mantenere il pdbs da qualche parte sicuro con la build e il codice sorgente corrispondenti. Se si verifica un arresto anomalo in tempo reale o simili, è possibile utilizzare il pdbs per eseguire il debug post-mortem utilizzando Debugging Tools for Windows o Visual Studio.