2

I try to implement a static analysis to check whether the method and its call graph will ever need the UI or Request (ASP.NET) context at all. The answer will decide the need for ConfigureAwait in the await statement(s) in the method body.

My plan is to use Roslyn to check the symbol of every member access in the call graph whether they are derived from System.Windows.UIElement class. Does this approach work? What about for ASP.NET context?

Tom K.
  • 6,549
  • 3
  • 14
  • 14
  • Do you want to target cases like [this](http://stackoverflow.com/q/28410046/1768303), where `ConfigureAwait(false)` actually adds some continuation marshaling overhead? – noseratio Feb 13 '15 at 00:36

2 Answers2

4

Any static analysis of this kind would be very difficult to implement correctly. You can use heuristics (e.g., UIElement), but you'll probably end up with some false positives and/or false negatives.

For example, FlowDocument does not derive from UIElement. You could change your heuristic to test for DispatcherObject-derived types, but then that would also include Freezable, which may or may not require context - you can't always know at compile-time. So that's a guaranteed false positive (or negative) in the general case.

As another example, adding items to a collection that is exposed as a data-bound property would also require the context, even though the collection is not a UI element.

Similar problems exist in ASP.NET. HttpContext.Current is obvious, but what about string formatting methods that implicitly use the current culture? There's a number of "gotchas" on the ASP.NET side, too.

That said, I do think it's a good idea; just be sure to have an easy way to ignore false positives and false negatives.

Stephen Cleary
  • 437,863
  • 77
  • 675
  • 810
1

I think it's a simple as comparing the number of occurences of the string 'await' and the string 'ConfigureAwait' in the same file.

It could be naive but a first line of defense.

Dave Van den Eynde
  • 17,020
  • 7
  • 59
  • 90