In Visual Studio 2013 molti investimenti sono stati fatti sul debugger. Una delle novità riguarda l'analisi delle operazioni asincrone basate sul pattern Async/Await, già introdotto con .NET 4.5.
Una nuova finestra, chiamata Tasks, ci aiuta nel capire l'andamento delle operazioni asincrone. Supponiamo di avere una banale applicazione WPF che mostra l'elenco di file nella directory C:\. Lato XAML ho un pulsante chiamato Button1 e una TextBox chiamata FileBox. Ripeto, l'applicazione è di proposito banale e di proposito usa 3 operazioni asincrone così stabilite (che poi non sia ortodosso è un'altra questione 
):
Private Async Sub Button_Click(sender As Object, e As RoutedEventArgs) Await Start() End Sub Private Async Function GetFiles() As Task(Of IEnumerable(Of String)) Dim result = Await Task.Run(Function() As IEnumerable(Of String) Return IO.Directory.EnumerateFiles("C:\") End Function) Return result End Function Private Async Function Start() As Task Dim files = Await GetFiles() Dim builder As New System.Text.StringBuilder For Each item In files builder.AppendLine(item) Next Me.FileBox.Text = builder.ToString End Function
La finestra Tasks non viene attivata in automatico. Dovete porre un punto di interruzione da qualche parte, in questo caso provatelo sulla Return nel metodo GetFiles, e poi quando l'applicazione è in esecuzione la trovate in Debug, Windows, Tasks.
In fase di debug, la finestra Tasks si presenta in modo simile alla figura:
Quindi:
- Lo stato Active indica l'operazione asincrona (Task, per l'appunto) in corso di esecuzione mentre Scheduled sta a significare che il runtime ha schedulato un'operazione per la successiva esecuzione.
- La colonna Task descrive il tipo di operazione e l'eventuale punto in cui c'è un operatore Await che ne attende l'esito
- La colonna Location indica la posizione all'interno dell'operazione asincrona. In figura si vede come per l'operazione attiva sia in corso di invocazione la macchina a stati che il runtime genera dietro le scene per le operazioni async (MoveNext)
Considerato il codice (puramente) dimostrativo, la prima operazione ad essere eseguita è GetFiles, attesa con Await da Start, attesa con Await dall'evento Click del pulsante. Ciò posto, è evidente il perché della sequenza degli stati nella finestra Tasks.
Il nome della finestra ci riporta alla mente il fatto che le operazioni asincrone nel pattern Async/Await sono basate sul concetto di task e sulla classe System.Threading.Tasks.Task. Le relative voci sull'esecuzione della macchina a stati, ci riportano alla mente l'architettura di runtime che supporta il pattern.
Se questi concetti non vi sono familiari, visitate le aree Articoli e Video di VB T&T e comprate il mio libro Visual Basic 2012 Unleashed dove il tutto è descritto nel dettaglio 
Alessandro