I consigli degli esperti italiani per sfruttare al meglio gli strumenti di sviluppo e semplificare l’attività quotidiana.

In questa pagina

 Abilitare il supporto all’ “Attach to process” nel .NET Compact Framework 2.0
 Team Foundation Server: gestire efficacemente la storia dei Work Item

Abilitare il supporto all’ “Attach to process” nel .NET Compact Framework 2.0

Di Lorenzo Barbieri - Microsoft MVP

Durante lo sviluppo di applicazioni, una delle esigenze principali è quella di effettuarne il debug al fine di verificarne il corretto funzionamento o di individuare bug.

Oltre al classico sistema di debug (avviando l’applicazione direttamente da Visual Studio in modalità Debug), ci sono situazioni in cui risulta comodo avviare prima l’applicazione e, solo successivamente, “agganciarci” il debugger per controllarne il comportamento.
Tale esigenza non è solo una questione di comodità, ma in alcuni casi diviene proprio una necessità, come ad esempio il debug di applicazioni per dispositivi mobili che fanno uso di State and Notification Broker, ed in modo particolare della funzionalità di ApplicationLauncher. In questo caso specifico infatti, l’applicazione viene avviata solo dopo lo scatenarsi dell’evento registrato, rendendo di fatto inutile l’avvio dell’applicazione in modalità debug da Visual Studio.

Sfortunatamente, se si prova ad agganciarsi all’applicazione in esecuzione sul dispositivo (o sull’emulatore) attraverso il menù Debug Attach to Process di Visual Studio 2005, l’operazione andrà in errore specificando all’utente l’impossibilità di essere eseguita.

Questo avviene in quanto, di default, sul .NET Compact Framework 2.0, il supporto alla funzionalità di “Attach to process” è disabilitata. Per abilitarla, dovremmo eseguire una modifica al registro del dispositivo usando il tool Remote Registry Editor, solitamente installato nella directory C:\Program Files\CE Remote Tools\5.01\bin\ccregedt.exe .

Una volta avviato, dovremmo selezionare il device a cui vogliamo connetterci (ad esempio l’emulatore – vedi Fig. 1), andare nella chiave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFramework e verificare la presenza della chiave “Managed Debugger”.

Figura 1: Scelta del device

Qualora non ci fosse, andrà creata cliccando con il tasto destro del mouse all’sulla chiave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFrameworke selezionando la voce “New Key” (vedi Fig. 2).

Figura 2: Aggiunta chiave

Fatto questo, non ci resta che aggiungere una nuova DWORD chiamata AttachEnabled il cui valore deve essere 1(vedi Fig. 3).

Figura 3: DWORD

Una volta completata questa operazione, sarà sufficiente eseguire un soft reset del dispositivo (o dell’emulatore) per rendere effettiva la modifica.
Da questo punto in poi, utilizzando il menù Debug Attach to Process di Visual Studio 2005 (vedi Fig. 4), potremmo agganciare il debugger alla nostra applicazione in esecuzione ed eseguirne in debug senza problemi.

Figura 4: Attach to process

E’ importante sottolineare che, qualora stiamo eseguendo questa operazione su un device reale, per questioni di performance sarebbe opportuno riportare il comportamento a quello di default. Per farlo sarà sufficiente impostare il valore della DWORD appena creata a 0.

 Inizio pagina

Team Foundation Server: gestire efficacemente la storia dei Work Item

Di Lorenzo Barbieri - Microsoft MVP

La gestione integrata dei Work Item è una delle caratteristiche salienti di Team Foundation Server e lo differenziano dalla maggior parte degli strumenti di gestione del codice sorgente, permettendogli di gestire in maniera integrata Bug, requisiti, rischi, task, ed in generale tutte le attività di progetto e tutte le richieste di modifica.

Un campo che spesso viene trascurato perché non se ne conosce bene l’utilizzo è il campo contenente la storia del Work Item (visibile in Figura 1).

Figura 1

Questo campo viene aggiornato ogni volta che si salva il Work Item, e contiene la data e l’ora di ogni salvataggio (o modifica effettuata automaticamente tramite il modello ad oggetti di Team Foundation Server o tramite i Web Services) e l’elenco di tutti i campi cambiati, oltre ad un campo di testo (visibile con la scritta “Type your comment here”) che può essere usato per descrivere la modifica effettuata.

Ad esempio, in Figura 1 si vede che i cambiamenti effettuati dal Team Explorer quando si è associato al Work Item il risultato di un’operazione di Check In del codice sorgente (identificata dalla scritta “changeset” e da un numero progressivo) vengono tracciati e viene aggiunta una riga che identifica il tipo di cambiamento effettuato (ad esempio “Associated with changeset” o “Resolved with changeset).

Nella storia viene anche indicato il cambiamento del numero totale di link presenti, ma non vengono indicati i link effettivamente presenti.

Si vede anche che quando il Work Item cambia di stato (nell’esempio da attivo a risolto) vengono modificate automaticamente anche una serie di informazioni, come la data di cambio di stato, la data in cui è stato risolto, etc…

Il commento presente nella storia può essere usato per descrivere le modifiche effettuate agli altri campi, in modo da semplificare il tracciamento delle modifiche stesse. I campi (ad esempio il campo descrizione del Work Item) dovrebbero sempre contenere l’ultimo valore, mentre l’evoluzione temporale dovrebbe essere descritta nella storia (Figura 2).

Figura 2

Come si vede, i valori precedenti dei campi vengono sempre tracciati, e il commento nella storia aiuta ad interpretare le modifiche effettuate.

Il secondo possibile uso della storia è legato al tracciamento delle discussioni all’interno del team relativamente alla possibile evoluzione di un Work Item.

Non è necessario che ci siano modifiche ai campi per poter salvare un commento nella storia, e questo permette di utilizzare il campo commento come “strumento di comunicazione” tra i membri del team, strumento che mantiene però anche la storia della comunicazione effettuata (si veda la Figura 3, per comodità non si è cambiato utente, ma lo si è indicato nel commento stesso).

Figura 3

Se invece si preferisce allegare al Work Item una o più mail, o il log di una sessione di Chat, allora bisogna utilizzare gli Attachment dei Work Item (Figura 4).

Figura 4

Anche l’inserimento di un Attachment comporta solo la tracciatura del conto degli Attachment presenti, e non il loro contenuto (Figura 5).

Bisogna quindi documentare bene le modifiche effettuate, perché se ad esempio si rimuove un Attachment e lo si sostituisce con un altro, lasciando invariato il conto totale, la modifica non risulta tracciata nella storia del Work Item.

Figura 5

 Inizio pagina