ConfigureAwait 的静态分析答案

【问题标题】：Static Analysis for ConfigureAwaitConfigureAwait 的静态分析
【发布时间】：2015-06-13 19:08:42
【问题描述】：

我尝试实现静态分析来检查方法及其调用图是否需要 UI 或 Request (ASP.NET) 上下文。答案将决定方法主体中的 await 语句中是否需要 ConfigureAwait。

我的计划是使用 Roslyn 检查调用图中每个成员访问的符号是否派生自 System.Windows.UIElement 类。这种方法有效吗？对于 ASP.NET 上下文呢？

【问题讨论】：

【解决方案1】：

任何此类静态分析都很难正确实施。您可以使用启发式方法（例如，UIElement），但最终可能会出现一些误报和/或误报。

例如，FlowDocument 不是从 UIElement 派生的。你可以改变你的启发式来测试DispatcherObject派生的类型，但是那也包括Freezable，它可能需要也可能不需要上下文——你不能总是在编译时知道。所以在一般情况下，这是一个有保证的假阳性（或阴性）。

作为另一个示例，将项目添加到作为数据绑定属性公开的集合也需要上下文，即使该集合不是 UI 元素。

在 ASP.NET 中也存在类似的问题。 HttpContext.Current 很明显，但是隐式使用当前文化的字符串格式化方法呢？ ASP.NET 方面也有许多“陷阱”。

也就是说，我确实认为这是个好主意；只要确保有一个简单的方法来忽略误报和漏报。

【讨论】：

【解决方案2】：

我认为这是一个简单的比较字符串'await'和字符串'ConfigureAwait'在同一个文件中的出现次数。

这可能很幼稚，但它是第一道防线。

【讨论】：