库中的 ConfigureAwait(true)

Question

我有一个 ASP.NET WebForms 应用程序，它的页面使用Async=True，我在我的OnLoad 方法中使用RegisterAsyncTask(new PageAsyncTask(InitialiseAsync)); 异步调用业务逻辑。

现在我知道 ASP.NET WebForms 需要在异步调用之后加上 ConfigureAwait(true)，因为它需要返回到原始同步上下文才能完成页面。然而，异步调用链进入库程序集（也是我们构建的）。库不需要知道，也不需要关心同步上下文来完成它的异步工作。此外，它可以（可能）用于其他环境，例如控制台应用程序。

因此：

1. 库方法是否应该始终使用ConfigureAwait(true)（以防它被上下文敏感的应用程序（例如 ASP.NET Web 窗体）使用）？或
2. 库方法可以使用ConfigureAwait(false)，WebForms 应用可以使用ConfigureAwait(true)吗？或
3. （我确定这不是答案，但是...）我是否应该将布尔值传递给库，说明是使用ConfigureAwait(true) 还是ConfigureAwait(false)？

到目前为止，我一直在使用选项 1，但我现在怀疑我应该使用选项 2，以便库代码可以 await 回到 any 线程并且应用程序将当调用堆栈返回时，最终上下文切换回必需上下文线程。

是这样吗？谢谢

Answer 1

ConfigureAwait 是一个只需要每个函数做出的决定。如果一个特定的函数需要返回它的上下文，那么它不应该使用ConfigureAwait(false)；否则，它可能会使用它。 caller 函数是否需要上下文无关紧要。当它的调用者awaits 时，它可以自己决定是否使用ConfigureAwait(false)。所以永远不要使用选项（3）。

您可以选择选项 (2)，这就是我目前会选择的选项。 ConfigureAwait(false) 确实有一些好处。然而，目前对这个问题的看法正在发生转变，主要是因为 ASP.NET Core 没有上下文（所以ConfigureAwait(false) 是个问题，人们不喜欢它弄乱他们的代码） .对于我自己，我仍然在库代码中使用ConfigureAwait(false)，但是其他一些开发人员已经从他们的库中完全删除了ConfigureAwait(false)。这相当于您的选项 (1)。这些选项中的任何一个都行得通；如果性能不是问题，它只是归结为偏好。