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.
feature jest bardzo fajny, bo debugowanie async’ow w jest strasznie męczące, tylko że haczykiem jest windows 8.1, jakies tipy w związku z WIN 7 ?
@szepiet:
Z tego co wiem, to jest jakis feature z Windows 8.1 i nawet na Windows 8.0 nie bedzie to dzialac.