July 8, 2009
@ 08:20 PM
Comments [0]
Quando Visual Studio non si lascia più governare...

Ultimamente sto avendo parecchi problemi nel debug di una grossa applicazione .NET 2.0 scritta in VB.NET che conta più di 70 progetti. Molto frequentemente, quando attivo di debugger di Visual Studio oppure provo ad "attaccarmi" al processo di ASP.NET (aspnet_wp.exe) l'operazione fallisce miseramente con un dialog del tipo:

error.GIF

Questo molte volte provoca il crash dell'IDE più l'abort del thread ASP.NET dell'applicazione che cercavo di analizzare. Il tutto alla fine si traduce in una enorme perdita di tempo.

Per risolvere il problema ho individuato due soluzioni:

1) Riavvio di Visual Studio prima del debug + IISRESET + Riavvio del servizio "Machine Debug Manager" (che si occupa direttamente dei debug locali e remoti).

Partendo da questa situazione "pulita" 1 volta su 2 riesco a debuggare, fissare breakpoint e fare trace nella succitata applicazione. Immagino che il problema origini dal fatto che l'enorme complessità e vastità di tale applicazione determini una quantità di simboli da caricare in fase di debug non indifferente, e per una ragione o per l'altra (out of memory, probabilmente) qualcosa va storto.

2) Soluzione più sicura e con maggiore percentuale di successo (100% per il momento) è di installare ed utilizzare per i soli debug il Microsoft CLR Debugger, tool decisamente più snello e veloce di Visual Studio per questo genere di cose.

Attaccarsi al processo di ASP.NET è una operazione veloce e senza problemi, e fare trace nel codice è particolarmente veloce. Ovviamente è possibile ispezionare il contenuto di oggetti live (Watch) e di posizionare breakpoint nel codice (anche condizionali). A tale scopo, è sufficiente aprire un file di codice relativo alla build che si sta debuggando, quindi inserire il breakpoint dove si vuole. Questo è dovuto al fatto che nei file di simboli (.PDB) i riferimenti alle path dei file sorgente sono sempre assoluti.

Il Microsoft CLR Debugger è incluso nel .NET Framework 2.0 Software Development Kit (SDK), scaricabile qui.


 
« 2 Miei Articoli su UGIdotNET | Home | Un poco di Kernel fa sempre bene (Parte ... »