Come eseguire il debug (passaggio in) di una libreria di classi a cui si fa riferimento nel mio progetto e che ha .pdb e il codice sorgente?

Quando eseguo il debug della soluzione / progetto aperto in Visual Studio (2015), desidero eseguire il debug (passaggio in) di una chiamata al metodo che si trova in uno degli assembly di riferimento. L’assembly ha .pdb (copiato localmente) e il codice sorgente. Questo assembly è in realtà anche il mio progetto lib di class, ma non nella soluzione corrente, invece in un’altra soluzione.

So che la soluzione banale per eseguire il debug di questo assembly sarebbe aggiungere il suo progetto alla soluzione corrente invece di fare riferimento a esso, quindi l’esperienza di debug sarebbe senza soluzione di continuità. Tuttavia, per alcuni motivi questo non sarebbe troppo efficiente nel mio caso, ad esempio ci sono molti assembly (dozzine) che dovrei aggiungere e non voglio finire con una soluzione gigante.

Quello che ho fatto / provato finora:

  • Ho deselezionato solo il mio codice
  • Ho controllato che .pdb per l’altro assembly è stato copiato nella cartella di output del mio progetto corrente.
  • Ho cercato di impostare un breakpoint appena prima della chiamata, quindi intervenire. Nessun successo, la chiamata è stata appena superata .
  • L’assembly che desidero eseguire il debug viene fornito come pacchetto NuGet (non un semplice riferimento sfogliato). È ancora vero, è il mio progetto lib di class, viene fornito con .pdb e il codice sorgente è disponibile nel mio disco locale.
  • Ha esaminato Finestra-> Debug-> Moduli: stato del simbolo: simboli caricati. Codice utente: N / A. La posizione del file di simboli è un file Temp Asp. (È un’applicazione ASP.NET MVC)
  • Poiché proviene da un pacchetto NuGet, la sua build è una build Release, ma attualmente non ottimizzata, e ha la versione aggiornata .pdb

Ricordo che questa funzione di debug è stata talvolta sorprendentemente lavorata in modo automatico, ma ora non è così.

Cosa mi manca?

I motivi più comuni di tale esperienza sono:

  1. abilitato “solo il mio codice” (strumenti-> opzioni-> debug)
  2. PDB non corrispondenti
  3. fonti non corrispondenti

Hai escluso 1, quindi per controllare gli altri 2:

Apri Debug-> Windows-> Moduli e trova l’assembly con cui stai avendo problemi. Assicurati che sia caricato dalla posizione che ti aspetti, con la versione che ti aspetti, controlla se i PDB sono caricati. Potrebbe essere necessario provare a caricare / ricaricare il PDB per vedere se VS è felice con il PDB localizzato.

Se i PDB stanno corrispondendo, VS dovrebbe iniziare a chiedere informazioni sulla posizione della fonte. Le informazioni sull’origine fanno parte del PDB, quindi ti consentiranno di sapere se la sorgente corrisponde o meno (esiste un’opzione per consentire il caricamento di file di origine non corrispondenti, ma avrai un’esperienza di debugging divertente).

Si noti che se la libreria di build per RELEASE sarà ottimizzata e per alcune funzioni non sarà ansible eseguirne il debug a causa dell’inallineamento in tempo JIT o dell’ottimizzazione del tempo di compilazione del codice morto (come if (false) rami if (false) ). Per una migliore esperienza, assicurati di utilizzare l’assembly DEBUG con il PDB corrispondente e assicurati di collegarlo in anticipo con “sopprimi le ottimizzazioni al caricamento” nelle opzioni del debugger.

Ho affrontato anche questo problema e ho provato molti suggerimenti. Eppure ho scoperto che il problema nel mio contesto era:

  • Il .dll desiderato è stato installato in GAC (Global Assembly Cache).

L’ho rimosso e ho potuto inserire nuovamente il codice dll.

Ho bisogno di farlo molte volte e l’approccio semplice che ho seguito è:

1) Assicurarsi che la libreria di classi che si desidera eseguire il debug sia compilata con il codice sorgente più recente

2) Copiare i file dll e .pdb dalla directory bin / debug della libreria di classi nella directory di output dell’applicazione

3) Avvia l’applicazione withattaching debugger (se si tratta di un’applicazione web, accedi direttamente dal browser e se è console / winform / wpf – fai clic su rispettivo exe)

4) Albind Visual Studio aperto con codice sorgente libreria di classi con quel particolare processo exe (o processo di lavoro IIS WP3 per applicazione web) e tutti pronti per partire !!