W VS 2013 usprawniono debugowanie kodu asynchronicznego. Wszyscy jesteśmy przyzwyczajeni już do async\await. Znacząco to ułatwia wykonywanie operacji asynchronicznych. Niestety, debugowanie w VS 2012 jest dość uciążliwe. Załóżmy, że mamy kod z wieloma metodami asynchronicznymi, które z kolei są pozagnieżdżane. W przypadku wyrzucenia wyjątku lub ustawienia breakpoint’a, call stack nie zawierał żadnych informacji. Przetestujmy opisany problem  na następującym kodzie:

public partial class MainWindow : Window
{
   public MainWindow()
   {
       InitializeComponent();
       DoSomething();
   }   
   private async void DoSomething()
   {
       await RunAsync();
   }

   private async Task RunAsync()
   {
       await Task.Delay(100);
       
       await DownloadNumberAsync();
   }
   private Task<int> DownloadNumberAsync()
   {
       return Task<int>.Factory.StartNew(DownloadNumber);
   }
   private int DownloadNumber()
   {   
       return 1;
   }
}

W Visual Studio 2012, gdy ustawimy breakpoint na linię await DownloadNumberAsync, call stack wyglądał następująco:

Z kolei w VS 2013 mamy pełny stos:

Dzięki ulepszeniom w VS 2013 i Windows 8.1, dużo łatwiej zrozumieć kod asynchroniczny. Wcześniej call stack pokazywał wyłącznie ostatnią metodę i nie wiadomo było, jak ona została wywołana. Na blogu kiedyś opisywałem internale async\await. Wiemy, że jest tam w rzeczywistości maszyna stanu, oparta na callbackach. Z tego względu, w poprzednich wersjach VS, nie wiadomo było jak metoda była wywołana. VS 2013 rozpoznaje konstrukcje async\await i można już je zaprezentować w sposób, który wynika z kodu c#, a nie implementacji w CLR.