Rilascio di generazione di file .pdb, perché?

Perché Visual Studio 2005 genera i .pdbfile durante la compilazione in versione? Non eseguirò il debug di una build di rilascio, quindi perché vengono generati?

Perché senza i file PDB, sarebbe impossibile eseguire il debug di una build "Release" con qualcosa di diverso dal debug a livello di indirizzo. Le ottimizzazioni fanno davvero un numero sul tuo codice, rendendo molto difficile trovare il colpevole se qualcosa va storto (diciamo, viene generata un'eccezione). Anche l'impostazione dei punti di interruzione è estremamente difficile, poiché le righe del codice sorgente non possono essere abbinate una a una (o anche nello stesso ordine) del codice assembly generato. I file PDB aiutano te e il debugger, facilitando notevolmente il debug post mortem.

Fai notare che se il tuo software è pronto per il rilascio, a quel punto avresti dovuto eseguire tutto il debug. Anche se questo è certamente vero, ci sono un paio di punti importanti da tenere a mente:

1. Dovresti anche testare ed eseguire il debug della tua applicazione (prima di rilasciarla) usando la build "Release". Questo perché l'attivazione delle ottimizzazioni (sono disabilitate per impostazione predefinita nella configurazione "Debug") a volte può far apparire bug sottili che altrimenti non verrebbero colti. Quando esegui questo debug, vorrai i simboli PDB.

2. I clienti segnalano spesso casi limite e bug che affiorano solo in condizioni "ideali". Queste sono cose che sono quasi impossibili da riprodurre in laboratorio perché si basano su una configurazione bizzarra della macchina di quell'utente. Se sono clienti particolarmente utili, segnaleranno l'eccezione generata e ti forniranno una traccia dello stack. Oppure ti permetteranno persino di prendere in prestito la loro macchina per eseguire il debug del software in remoto. In entrambi i casi, ti consigliamo i file PDB per aiutarti.

3. La creazione di profili dovrebbe sempre essere eseguita su build "Release" con ottimizzazioni abilitate. E ancora una volta, i file PDB sono utili, poiché consentono di mappare le istruzioni di assemblaggio da profilare sul codice sorgente effettivamente scritto.

Non è possibile tornare indietro e generare i file PDB dopo la compilazione. ^* Se non li crei durante la creazione, hai perso l'opportunità. Non fa male a nulla crearli. Se non vuoi distribuirli, puoi semplicemente ometterli dai tuoi binari. Ma se in seguito decidi di volerli, sei sfortunato. Meglio generarli sempre e archiviarne una copia, nel caso in cui ne abbiate mai bisogno.

Se vuoi davvero spegnerli, è sempre un'opzione. Nella finestra Proprietà del progetto, imposta l'opzione "Informazioni debug" su "nessuna" per qualsiasi configurazione che desideri modificare.

Do atto, tuttavia, che le configurazioni "Debug" e "Stampa" lo fanno con l'uso di default diverse impostazioni per l'emissione di informazioni di debug. Ti consigliamo di mantenere questa impostazione. L'opzione "Informazioni debug" è impostata su "completo" per una build di debug, il che significa che oltre a un file PDB, le informazioni sui simboli di debug sono incorporate nell'assembly. Ottieni anche simboli che supportano funzioni interessanti come modifica e continua. Nella modalità di rilascio, viene selezionata l'opzione "solo pdb" che, come sembra, include solo il file PDB, senza influire sul contenuto dell'assembly. Quindi non è così semplice come la semplice presenza o assenza di file PDB nella tua /bindirectory. Ma supponendo che tu usi l'opzione "solo pdb", il file PDB "

_{^* Come sottolinea Marc Sherman in un commento , purché il codice sorgente non sia cambiato (o sia possibile recuperare il codice originale da un sistema di controllo della versione), è possibile ricostruirlo e generare un file PDB corrispondente. Almeno, di solito. Funziona bene per la maggior parte del tempo, ma non è garantito che il compilatore generi binari identici ogni volta che compili lo stesso codice , quindi potrebbero esserci sottili differenze. Peggio ancora, se nel frattempo hai apportato aggiornamenti alla tua toolchain (come applicare un service pack per Visual Studio), i PDB hanno ancora meno probabilità di corrispondere. Garantire la generazione affidabile di ex postfactoPer i file PDB, è necessario archiviare non solo il codice sorgente nel sistema di controllo della versione, ma anche i file binari dell'intera toolchain di build per garantire che sia possibile ricreare con precisione la configurazione del proprio ambiente di build. Inutile dire che è molto più semplice creare e archiviare semplicemente i file PDB.}

PDB può essere generato sia per Releaseche per Debug. Questo è impostato su (in VS2010 ma in VS2005 deve essere simile):

Progetto → Proprietà → Crea → Avanzate → Informazioni di debug

Basta cambiarlo in None.

Senza i file .pdb è praticamente impossibile scorrere il codice di produzione; devi fare affidamento su altri strumenti che possono essere costosi e richiedere molto tempo. Capisco che puoi usare la traccia o windbg per esempio, ma dipende davvero da cosa vuoi ottenere. In alcuni scenari si desidera semplicemente scorrere il codice remoto (senza errori o eccezioni) utilizzando i dati di produzione per osservare comportamenti particolari, ed è qui che i file .pdb sono utili. Senza di loro è impossibile eseguire il debugger su quel codice.

Perché sei così sicuro di non eseguire il debug delle build di rilascio? A volte (si spera raramente, ma succede), potresti ricevere da un cliente un rapporto sui difetti che non è riproducibile nella versione di debug per qualche motivo (tempistiche diverse, comportamenti diversi o altro). Se quel problema sembra essere riproducibile nella build di rilascio, sarai felice di avere il pdb corrispondente.

Inoltre, è possibile utilizzare i dump di arresto anomalo per eseguire il debug del software. Il cliente te lo invia e quindi puoi usarlo per identificare la versione esatta del tuo sorgente - e Visual Studio tirerà anche il giusto set di simboli di debug (e sorgente se impostato correttamente) usando il dump di crash. Consulta la documentazione di Microsoft su Symbol Stores .

Il file .PDB è il nome breve di "Database di programma". Contiene le informazioni sul punto di debug per il debugger e le risorse utilizzate o di riferimento. Viene generato quando costruiamo come modalità di debug. Permette all'applicazione di eseguire il debug in fase di esecuzione.

La dimensione è l'aumento del file .PDB in modalità debug. Viene utilizzato quando stiamo testando la nostra applicazione.

Buon articolo di file pdb.

http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P

In una soluzione multiprogetto, di solito si desidera avere una configurazione che non generi affatto file PDB o XML. Invece di modificare la Debug Infoproprietà di ogni progetto in none, ho pensato che sarebbe più opportuno aggiungere un evento post-build che funzioni solo in una configurazione specifica.

Sfortunatamente, Visual Studio non consente di specificare diversi eventi post-build per diverse configurazioni. Quindi ho deciso di farlo manualmente, modificando il csprojfile del progetto di avvio e aggiungendo quanto segue (anziché qualsiasi PostBuildEventtag esistente ):

  <PropertyGroup Condition="'$(Configuration)' == 'Publish'">
    <PostBuildEvent>
        del *.pdb
        del *.xml
    </PostBuildEvent>
  </PropertyGroup>

Sfortunatamente, questo renderà vuota la casella di testo dell'evento post build e inserendo qualsiasi cosa in essa può avere risultati imprevedibili.

I simboli di debug ( .pdb) e i file doc XML ( .xml) rappresentano una grande percentuale della dimensione totale e non dovrebbero far parte del pacchetto di distribuzione normale. Ma dovrebbe essere possibile accedervi nel caso in cui siano necessari.

Un possibile approccio: al termine del processo di compilazione di TFS, spostali in un artefatto separato.

In realtà senza file PDB e informazioni simboliche non sarebbe possibile creare un rapporto sugli arresti anomali di successo (file di dump della memoria) e Microsoft non avrebbe il quadro completo della causa del problema.

E così avere PDB migliora la segnalazione degli arresti anomali.