Jasne jest, dlaczego nowe paradygmaty programowania Microsoftu wpływają na śledzenie stosu. Mamy teraz stos semantyczny i kilka fizycznych (mój wybór słów).

To, co widzę, to wyjątekStackTrace właściwość (i debugger) to właściwości fizyczne, połączone:

private async Task CheckFooAndBar()
{
    var log = LogManager.GetLogger("Test");
    log.Info("CheckFooAndBar");
    try
    {
        await Foo();
    }
    catch (Exception ex)
    {
        log.Info("StackTrace of last exception: " + ex.StackTrace);
    }
    Console.ReadKey();
}
private async Task Foo()
{
    await Task.Factory.StartNew(() => Thread.Sleep(1000));
    await Bar();
    await Task.Factory.StartNew(() => Thread.Sleep(1000));
}
private async Task Bar()
{
    await Task.Factory.StartNew(() => Thread.Sleep(1000));
    throw new Exception();
    await Task.Factory.StartNew(() => Thread.Sleep(1000));
}

To daje:

StackTrace of last exception:    at NLogAsyncExceptionTestCase.Program.<Bar>d__d.MoveNext() in c:\Users\Jens\Documents\Visual Studio 2012\Projects\NLogAsyncExceptionTestCase\NLogAsyncExceptionTestCase.Console\Program.cs:line 53
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
   at NLogAsyncExceptionTestCase.Program.<Foo>d__8.MoveNext() in c:\Users\Jens\Documents\Visual Studio 2012\Projects\NLogAsyncExceptionTestCase\NLogAsyncExceptionTestCase.Console\Program.cs:line 44
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
   at NLogAsyncExceptionTestCase.Program.<CheckFooAndBar>d__0.MoveNext() in c:\Users\Jens\Documents\Visual Studio 2012\Projects\NLogAsyncExceptionTestCase\NLogAsyncExceptionTestCase.Console\Program.cs:line 30 

Moje pytanie brzmi: czy istnieje (wygodny, standardowy) sposób na przekształcenie go w odpowiedni ślad wsteczny w sensie semantycznym, taki jak:

CheckFooAndBar
Foo
Bar

Oczywiście na stosie może być mieszanka oczekujących i fragmentów ścieżki.

Próbowałem patrzeć na stos, tak jak w przypadku .NET 4.5 i SL5 z asynchronicznym pakietem docelowym, ale jeszcze nie z WinRT. Dane wyjściowe pochodzą z .NET 4.5.

W SL5, co robię głównie, sytuacja jest bardziej problematyczna: nie ma numerów linii w śladach stosu w Silverlight (nawet z podwyższonymi uprawnieniami), co sprawia, że ​​potrzeba kontekstu jest ważniejsza.