与 ASP.NET Core 相关的 ConfigureAwait(false)？

.net asp.net-core async-await

我在 GitHub 上偶然发现了一个问题 (https://github.com/HTBox/allReady/issues/1313)，他们在该问题上讨论了将 ConfigureAwait(false) 从代码中取出，并声称在 ASP.NET Core 中

对 ConfigureAwait(false) 的调用是多余的，什么都不做

我能在这里找到的最好的答案是答案中的“旁注”（来自 Stephen Cleary，https://stackoverflow.com/a/40220190/2805831）告诉

ASP.NET Core 不再有“上下文”

那么，ASP.NET Core 中真的不需要 ConfigureAwait(false)（即使使用完整的 .Net Framework）？在某些情况下，它在性能上是否有任何真正的提升或结果/语义上的差异？

编辑：如果我将它作为控制台应用程序或在 IIS 中托管，在这方面有什么不同吗？

这取决于您计划在哪里使用它。如果您想直接在您的 ASP.NET Core 应用程序中使用它，那么您不必调用它（您不必在 ASP.NET legacy 和 iirc 中调用它）。但是如果您编写一个库，那么您应该始终使用 ConfigureAwait(false)，因为该库可以被不同的应用程序（ASP.NET Core、WPF、UWP、控制台等）使用。

ASP.NET Core 默认作为控制台应用程序运行，AFAIK 控制台应用程序没有 SynchronizationContext，所以是的，这对于默认的 ASP.NET Core 应用程序来说是合理的，即使使用完整的框架也是如此。

@JoeWhite 好的，编辑了问题。如果我的 ASP.NET Core 应用程序位于 IIS 中，会有所不同吗？

在 IIS 中运行的 ASP.NET Core 应用程序仍然作为控制台应用程序运行 - 唯一的区别是 IIS 正在启动和关闭您的应用程序实例（与托管 ASP.NET 工作进程实例的方式相同）经典的 ASP.NET）。它不会改变您的 ASP.NET 应用程序中任何与线程相关的行为。（我指定“默认”的唯一原因是，例如，您可以在 GUI 应用程序中托管 ASP.NET Core，在这种情况下，您必须考虑同步上下文。）

注意 ConfigureAwait(false)，虽然在 ASP.NET 经典中相关，但绝不是必需。这是一个权衡：它有点减轻了一些同步异步死锁（无论如何都是设计缺陷——除非有人做一些愚蠢的事情，否则它们不存在）并且偶尔通过不重新加载上下文来提高约微秒的性能。以无法依赖上下文为代价，并且在您的代码中全部包含 ConfigureAwait。 stackoverflow.com/questions/28221508/…

Paulo Morgado

ConfigureAwait 仅对在 a SynchronizationContext 的上下文中运行的代码有影响，而 ASP.NET Core 没有（ASP.NET“旧版”有）。

通用代码应该仍然使用它，因为它可能正在运行带有SynchronizationContext。

ASP.NET Core SynchronizationContext

只是想稍微澄清一下，非核心环境中的 ASP.NET 确实有同步上下文，但 ASP.NET 核心没有。

@Morgado，即使应用程序托管在 IIS 中也是如此吗？

ASP.NET Core 应用程序不托管在 IIS 中。 IIS 只是充当反向代理。

我已经用 Stephen Cleary 最近的一篇文章更新了答案。但是，是的，ASP.NET Core 就是 ASP.NET Core。

@NamNgo。欣赏这是一篇旧帖子，但 Stephen Cleary 在上面 Paulo 链接的帖子的 questions 之一中澄清了这一点。 “决定 SynchronizationContext 的是框架（ASP.NET Core 与 ASP.NET Classic 相对），而不是运行时（.NET Core 与 .NET 4.6.2 相对）”

与 ASP.NET Core 相关的 ConfigureAwait(false)？

关注公众号

想领先一步获取最新的外包任务吗？

相似问题

平台

支持

联系我们