Devo compilare versioni di rilascio con informazioni di debug come "completo" o "solo pdb"?

114

In Visual Studio 2010 per un progetto C #, se vai a Proprietà progetto> Compila> Avanzate> Informazioni di debug hai tre opzioni: nessuna, completa o solo pdb. Sulla base della risposta a questa domanda , credo di aver compreso alcune delle differenze tra full e pdb-only. Tuttavia, qual è più appropriato per una build di rilascio? Se uso "full" ci saranno ramificazioni nelle prestazioni? Se utilizzo "solo pdb" sarà più difficile eseguire il debug dei problemi di produzione?

Qual'è la differenza tra "full" e "pdbonly"? https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/debug-compiler-option

— RationalGeek
fonte

Solo pdb o nessuno, sempre per build di rilascio.

— leppie

13

@leppie Grazie ma sto cercando una giustificazione per quella posizione.

— RationalGeek

Questione connessa: stackoverflow.com/questions/1270986/...

— janv8000

È fantastico se non c'è impatto sulle prestazioni. E l'impatto sulla memoria? Se creo un'istanza di StackTrace e richiedo informazioni sul file, devono provenire dai dati del simbolo pdb. Tutti i simboli vengono caricati in memoria all'avvio dell'applicazione? Qual è l'uso approssimativo della memoria di questo? (ad esempio, overhead percentuale relativo alla dimensione del codice.)

— yoyo

90

Costruirei con pdb-only. Non sarai in grado di collegare un debugger al prodotto rilasciato, ma se ottieni un crash dump, puoi usare Visual Studio o WinDBG per esaminare le tracce dello stack e le dump della memoria al momento dell'arresto anomalo.

Se scegli fullinvece di pdb-only, otterrai gli stessi vantaggi, tranne per il fatto che l'eseguibile può essere collegato direttamente a un debugger. Dovrai determinare se questo è ragionevole considerando il tuo prodotto e i tuoi clienti.

Assicurati di salvare i file PDB da qualche parte in modo da poterli fare riferimento quando arriva un rapporto di arresto anomalo. Se puoi impostare un server di simboli per memorizzare quei simboli di debug, tanto meglio.

Se scegli di costruire con none, non avrai ricorso in caso di crash sul campo. Non sarai in grado di eseguire alcun tipo di esame a posteriori dell'incidente, che potrebbe ostacolare gravemente la tua capacità di rintracciare il problema.

Una nota sulle prestazioni:

Sia John Robbins che Eric Lippert hanno scritto post di blog sulla /debugbandiera ed entrambi indicano che questa impostazione ha un impatto zero sulle prestazioni . C'è un /optimizeflag separato che stabilisce se il compilatore debba eseguire le ottimizzazioni.

— Matt Dillard
fonte

7

@ Matt, l' articolo MSDN sull'opzione / debug avverte esplicitamente dell'impatto sulle prestazioni dell'utilizzo dell'impostazione "completa":

If you use /debug:full, be aware that there is some impact on the speed and size of JIT optimized code and a small impact on code quality with /debug:full. We recommend /debug:pdbonly or no PDB for generating release code.

— Allon Guralnek,

3

@ Matt: Se "full" non ha svantaggi rispetto a "pdb-only", ma ha solo vantaggi, perché esiste anche "pdb-only"? C'è qualche motivo per usarlo più "pieno"? Inoltre, è necessario aggiungere la correzione all'articolo MSDN nella sezione "Contenuto della community".

— Allon Guralnek

9

@AllonGuralnek citazione dall'articolo di John Robbins collegato: La vera ragione: la storia. In .NET 1.0 c'erano delle differenze, ma in .NET 2.0 non ci sono. Sembra che .NET 4.0 seguirà lo stesso schema. Dopo un doppio controllo con il team di debug di CLR, non c'è alcuna differenza.

— Bentayloruk

5

Non è vero. Puoi creare solo con pdb e allegare comunque un debugger. L'ho fatto solo per essere sicuro.

— Marco

2

"Vorrei compilare solo con pdb. Non sarai in grado di allegare un debugger al prodotto rilasciato" Qual è la tua fonte di informazioni qui? Come abbiamo notato sia io che @Mark, questo non sembra essere corretto.

— MEMark

66

AVVISO La documentazione MSDN per l'opzione / debug (in Visual Studio è Informazioni di debug) sembra non essere aggiornata! Questo è ciò che ha che non è corretto

Se usi / debug: full , tieni presente che c'è un certo impatto sulla velocità e sulla dimensione del codice ottimizzato JIT e un piccolo impatto sulla qualità del codice con / debug: full . Consigliamo / debug: pdbonly o no PDB per la generazione del codice di rilascio.

Una differenza tra / debug: pdbonly e / debug: full è che con / debug: full il compilatore emette un DebuggableAttribute, che viene utilizzato per dire al compilatore JIT che sono disponibili informazioni di debug.

Allora, cosa è vero adesso?

Solo PDB : prima di .NET 2.0, aiutava a esaminare i dump di arresto anomalo del prodotto rilasciato (macchine del cliente). Ma non ha permesso di collegare il debugger. Questo non è il caso di .NET 2.0. È esattamente lo stesso di Full .
Completo : questo ci aiuta a esaminare i dump di arresto anomalo e ci consente anche di collegare il debugger alla build di rilascio. Ma a differenza di quanto menzionato da MSDN, non influisce sulle prestazioni (a partire da .NET 2.0). Funziona esattamente come solo Pdb .

Se sono esattamente gli stessi, perché abbiamo queste opzioni? John Robbins (dio del debug di Windows) ha scoperto che esistono per ragioni storiche.

In .NET 1.0 c'erano delle differenze, ma in .NET 2.0 non ci sono. Sembra che .NET 4.0 seguirà lo stesso schema. Dopo un doppio controllo con il team di debug di CLR, non c'è alcuna differenza.

Ciò che controlla se JITter esegue una build di debug è l'opzione / optimize. <...>

La linea di fondo è che si desidera creare build di rilascio con / ottimizzare + e qualsiasi opzione / debug in modo da poter eseguire il debug con il codice sorgente.

poi continua a dimostrarlo.

Ora l'ottimizzazione fa parte di un interruttore separato /optimize(in Visual Studio si chiama Optimize code).

In breve, indipendentemente dall'impostazione di DebugInfo solo pdb o full, avremo gli stessi risultati. La raccomandazione è di evitare Nessuno poiché ti priverebbe della possibilità di analizzare i dump di arresto anomalo dal prodotto rilasciato o collegare il debugger.

— rpattabi
fonte

3

Risposta fantastica! Le mie indagini (confrontando i file generati) mostrano gli stessi risultati.

— MEMark

@rpattabi Puoi specificare il riferimento che pdbonly e full sono la stessa cosa? È il 2019 e la documentazione indica ancora che sono diversi e completi avranno un degrado delle prestazioni. E VS2019 crea il progetto con Releaseil tipo di debug della configurazione impostato per impostazione predefinita su pdbonly.

— Joe,

@joe C'è una discussione in fondo alla documentazione MSDN msdn.microsoft.com/en-us/library/8cw0bt21.aspx . Dai un'occhiata. Un collaboratore ha indicato github.com/dotnet/roslyn/blob/master/docs/compilers/CSharp/… per informazioni aggiornate in cui pdbonly e full sono menzionati allo stesso modo. (Cordiali saluti. Non uso più Windows o VS. Quindi non ho seguito ciò che sta accadendo lì. Ma come ho esaminato, le informazioni nella mia risposta sono ancora pertinenti e il documento MSDN è ancora errato.)

— rpattabi

16

Avrai bisogno solo del PDB, ma non vorrai dare i file PDB agli utenti. Tuttavia, averli per te, insieme ai tuoi binari, ti dà la possibilità di caricare i dump di arresto anomalo in un debugger come WinDbg e vedere dove il tuo programma ha effettivamente fallito. Questo può essere piuttosto utile quando il tuo codice si blocca su una macchina a cui non hai accesso.

Il debug completo aggiunge l'attributo [Debuggable] al codice. Questo ha un enorme impatto sulla velocità. Ad esempio, alcune ottimizzazioni del ciclo potrebbero essere disabilitate per rendere più semplice il passaggio singolo. Inoltre, ha un piccolo effetto sul processo JIT, poiché attiva il monitoraggio.

— blowdart
fonte

Ha senso. Non distribuisco comunque le DLL agli utenti: è un'app ASP.NET. Ma puoi migliorare la tua risposta e giustificare il motivo per cui dovresti scegliere "solo pdb" rispetto a "completo"? È un problema di prestazioni?

— RationalGeek

@jkohlhepp: vorrei aggiungere che il debug delle build di rilascio è un po 'complicato poiché perderai alcune informazioni (a causa di JIT). Quasi sempre, non sarai in grado di vedere i valori degli argomenti del metodo. Per risolvere questo problema, puoi disabilitare temporaneamente l'ottimizzazione JIT utilizzando questo .

— Ilian Pinzon

Grazie blowdart e grazie Ilian Pinzon per le informazioni aggiuntive. So che non puoi ottenere un debug perfetto con il codice di rilascio, ma avere i PDB è meglio di niente.

— RationalGeek

L'utilizzo dell'impostazione "completo" non ha un impatto sulle prestazioni. Consente semplicemente di collegare un debugger a un processo in esecuzione.

— Matt Dillard

1

Bella domanda su MSDN Matt, msdn.microsoft.com/en-us/library/8cw0bt21 , in attesa della risposta io stesso.

— Luke Hutton

4

Sono in procinto di scrivere un gestore di eccezioni non gestito e la traccia dello stack include il numero di riga quando viene utilizzato solo pdb, altrimenti ottengo solo il nome della Sub / Funzione quando scelgo Nessuno.

Se non distribuisco il .pdb non ottengo il numero di riga nella traccia dello stack anche con la build solo pdb.

Quindi, sto distribuendo (XCOPY deploy su una LAN) il pdb insieme all'exe dalla mia app VB.

— rheitzman
fonte