Malgrado cerchi di sviluppare secondo l’approccio TDD, ogni tanto (:D) ho necessità di utilizzare il buon vecchio debugger.

In questi giorni sto lavorando su uno snap-in custom realizzato in c# per la mmc consolle. A causa di inspiegabili (finchè non ho scoperto la causa…) malfunzionamenti ho deciso di procedere col debugging per capire cosa stava succedendo.

E qui cominciano i problemi: lo snap-in è un oggetto COM in-process (una dll) che a sua volta carica la dll col "mio” codice. Non sapevo come spiegare a VS2005 che il codice in esecuzione era quello che avevo aperto nell’ide. Ho pensato di utilizzare la capacità del debugger di agganciarsi ad un processo (un file .exe) ma i primi tentativi sono stati infruttuosi.

Vi risparmio i passaggi intermedi:

1. ho specificato come cartella per l’output di compilazione quella dove avevo installato una precedente versione dell’o snap-in (non è win\system32 ma una cartella sotto program files nel mio caso)

2. ho lanciato l’mmc e aperto lo snap-in

3. ho fatto da VS2005 l’attach to process… a mmc.exe

4. da mmc ho fatto new…

5. ho ricaricato il mio snap-in e… voilà il debugger si è fermato sul breakpoint che avevo posizionato sulla classe che costruiva un treeview di nodi (ognuno dei quali associato a una dll che esporta una propria funzionalità) nello snapin

Per qualche minuto sono stato veramente compiaciuto della mia scoperta ma cosa simpatica è stato constatare che non mi serviva a nulla!

I malfunzionamenti che osservavo erano dovuti al fatto che MMC carica (se esistono) prima le dll che trova sotto windows\system32 e poi (eventualmente) quelle che trova nella cartella dove viene registrato lo snapin (sotto program files\qualcosa nel mio caso).

Questo l’ho scoperto guardando quali dll l’mmc.exe stava caricando (e da dove) utilizzando l’ottimo ProcessExplorer.

Non si finisce mai di imparare…😀