416
Articolo archiviato: questo contenuto risale a oltre 5 anni fa e potrebbe non essere più aggiornato.
Introduzione.
Con il rilascio di Visual Studio 2015, avvenuto negli scorsi giorni, vi sono diverse novità per gli sviluppatori rispetto alla versione 2013. Una di queste è il supporto per il debug delle nostre applicazioni, che tratteremo in questi articoli. Questo è il primo di una piccola serie di sette mini articoli, dove spiegheremo con testo e immagini tutte le novità, i miglioramenti e le integrazioni di altri strumenti a quelli già esistenti. Facciamo prima un elenco degli argomenti che tratteremo:
- Diagnostic Tool
- Timeline Tool
- PerfTips
- Le nuove funzionalità dei BreakPoint
- BreakPoint condizionale
- Hit counts
- Tracepoints
- Debug sulle lambda Expression
- UI Debugging tool for XAML
- Network Tool
Diagnostic Tool.
Non si tratta di una vera e propria novità, con questo strumento possiamo:
- Verificare in realtime il consumo di memoria
- Verificare il consumo della cpu (tutti i processori)
- Avere un debugger events
- Verificare la quantità di risorse che consuma la nostra applicazione
- Verificare il livello di performance dell’applicazione
Come detto, questo strumento era disponibile anche in Visual Studio 2013, con la differenza che non era possibile visualizzare in una sola schermata quanto scritto nei punti precedenti. Se avviamo Visual Studio 2013 e aprendo un qualsiasi progetto (io uso la versione professional), dal menù DEBUG e subito dopo prestazioni e diagnostica, vedrete che nella schermata successiva selezionando “Utilizzo memoria” non sarà possibili attivare altri strumenti.
Cliccando sul tasto inizia, posto in basso a sinistra, partirà il debug della nostra applicazione e viene visualizzato il consumo di memoria come visibile in figura.
Arrestando il debug, potremo poi visualizzare attraverso un file di tipo diagsession tutti i risultati. Ma vediamo ora come questo strumento è stato modificato ma soprattutto migliorato in Visual Studio 2015. Avviamo Visual Studio 2015, apriamo un progetto qualsiasi, tasto F5 per avviare il debug, e ci accorgeremo già di una differenza, lo strumento Diagnostic tool parte automaticamente. Lo vediamo in basso mediante la finestra Strumenti di diagnostica come mostrato in figura.
Ma non è tutto; se confrontiamo questa immagine con quella precedente noteremo altri particolari ovvero:
-
la visualizzazione degli eventi di debugger, il consumo di memoria e l’utilizzo della cpu tutti in una sola schermata.
-
In alto a sinistra un menù a tendina dove possiamo scegliere di visualizzare o solo l’utilizzo di memoria o della cpu.
-
altre tre tipologie di visualizzazione che troviamo in basso all’immagine successiva, tra cui Debugger, si tratta di ciò che visualizziamo nella finestra di output al momento che compiliamo la nostra solution. “Utilizzo memoria” con la possibilità di creare degli snapshot, ovvero un visualizzatore di oggetti presenti in memoria, e avere maggiori dettagli con la possibilità di crearne altri per eseguire un poi un confronto, ed infine “Utilizzo CPU”; quest’ultimo però richiede che l’applicazione venga eseguita senza il Debug. Possiamo come in Visual Studio 2013 andare ovviamente a selezionare un lasso di tempo dove vediamo un eccessivo consumo di memoria e crearci come accennato degli snapshot come visibile nelle figure successive.
-
Abbiamo selezionato un lasso di tempo pari a 2,279 secondi, creato il primo snapshot, creiamone un altro.
In basso notiamo gli snapshot creati mediante il pulsante Crea snapshot, dove abbiamo l’ora, ovvero quando è stato creato, il primo dopo 20,09 secondi, gli altri due dopo 33,29 e 65,17 secondi dopo l’avvio dell’applicazione. Abbiamo la quantità di oggetti per ogni snapshot e la dimensione dello heap, in quest’ultimo abbiamo disponibile anche una visualizzazione delle differenze, data dalle frecce di colore rosso o verde che indicano se vi è stato un aumento o diminuzione degli oggetti tra uno snapshot e l’altro. Se con il mouse facciamo click su uno dei tre ecco cosa visualizzeremo.
Per ogni oggetto selezionato dalla lista Tipo di oggetto, possiamo vederne il dettaglio nella finestra sottostante dove abbiamo le diciture Percorsi della radice e Tipo a cui si fa riferimento, ma anche la quantità per ogni oggetto, la dimensione totale e inclusiva in byte. Tra questi oggetti ovviamente abbiamo quelli del dotnet framework, e ovviamente anche oggetti che aggiungiamo noi nel codice, quindi liste o altro. Altra cosa da vedere, sono i debugger events, ovvero una sorta di registratore di ogni evento che si verifica nella nostra applicazione, per esempio il click su un button. Per provare questa funzionalità, inseriamo un breakpoint all’evento click di un pulsante come mostrato in figura.
Avviamo il debug e facciamo click sul button, tornando alla visualizzazione della finestra Strumenti di diagnostica ci accorgeremo che è stato intercettato il nostro click e il debug è fermo sul break point.
Abbiamo nella sezione Eventi del debugger, dei rombi di colore grigio, nero e rosso. Il grigio è riferito agli eventi del codice esterno, il nero riferito all’interfaccia grafica mentre il rosso sta ad indicare che il debug è fermo sul break point. Se andiamo in dettaglio notiamo che il click sul button è stato eseguito 18,53 secondi dopo l’avvio dell’applicazione. Possiamo ancora mediante la casella a discesa Mostra tutte le categorie, filtrare il tipo di visualizzazione desiderato, come visibile in figura.
A noi interessa visualizzare gli eventi per cui selezioniamo la checkbox Debugger, ed ecco la visualizzazione dopo la selezione.
Ultima cosa, l’utilizzo della CPU, ma come detto, dobbiamo eseguirlo senza debug. Torniamo in Visual Studio 2015, nel menù Debug, selezioniamo il comando Avvia strumenti di diagnostica senza debug, alla successiva finestra andiamo a selezionare la voce Utilizzo CPU.
Click sul pulsante inizia, e sarà avviata l’applicazione, eseguiamo qualche click sul button verificando cosa accade.
Noteremo che ad ogni click nella sezione Utilizzo CPU, vi saranno cambiamenti, indicanti il consumo di CPU in un lasso di tempo. Cliccando ora sul button Arresta, posto in alto a sinistra l’applicazione sarà arrestata e creato un rapporto su file con estensione diagsession.
Come per l’utilizzo di memoria, possiamo selezione un arco di tempo e verificare l’utilizzo della CPU che vedremo nel dettaglio in basso alla schermata, e la possibilità anche qui di eseguire filtri per una visualizzazione più dettagliata.
Progetti supportati.
Al momento il diagnostic tool è supportato in queste tecnologie.
- Managed WPF, WinForms, Console projects
- Native Win32, Console, and MFC projects
- ASP.NET projects running on a local IIS and IIS Express
- Managed or Native Windows Store projects
- Debugging sessions started using Debug –> Attach to Process
- Debugging apps running on remote desktop devices
Non sono supportate invece:
- Windows Store projects that are using JavaScript
- Windows Store projects that are running on a Windows Phone
- Debugging when Managed or Native Compatibility Mode is checked in Tools –> Options –> Debugging
Conclusione.
In questo primo articolo, abbiamo esplorato il Diagnostic tool, con il quale siamo in grado di visualizzare l’utilizzo di memoria, di cpu e verificare tutti gli eventi verificatosi mediante la sezione Eventi del debugger. Abbiamo visto in che modo selezionare un lasso di tempo nella sezione Sessione di diagnostica e creare degli snapshot per la verifica della quantità di oggetti in memoria, per terminare con il tool Utilizzo CPU. Nel prossimo articolo faremo un introduzione su un nuovo strumento, non presente in Visual Studio 2013, il TimeLine tools.
