Braucht es ConfigureAwait noch?
- Matt
Ich stolpere gerade wieder über altes Codereview-Wissen: an jedem await steht ConfigureAwait(false), aus Gewohnheit aus der ASP.NET-Framework-Zeit. Lohnt sich das noch?
In ASP.NET Core gibt es standardmäßig gar keinen SynchronizationContext mehr, Continuations landen ohnehin im Thread Pool. ConfigureAwait(false) ändert dort also nichts am Verhalten - genau das schreibt Microsoft auch bei der zugehörigen Analyzer-Regel CA2007, die deshalb seit .NET 10 nicht mehr standardmäßig aktiv ist.
Anders sieht es in zwei Fällen aus: Bibliothekscode, der in beliebigen Umgebungen läuft, sollte weiterhin ConfigureAwait(false) setzen, weil man nicht weiß, ob ein Aufrufer einen Kontext mitbringt. Und in WPF- oder WinForms-Anwendungen braucht man die Continuation oft ausdrücklich auf dem UI-Thread - dort ist ConfigureAwait(false) sogar falsch.
Der Haken: Wer den Aufruf jetzt überall entfernt, muss sauber zwischen App- und Bibliotheksprojekten unterscheiden, sonst reißt man sich in einem wiederverwendbaren Paket den Boden unter den Füßen weg.
Details in der ConfigureAwait FAQ und bei CA2007.