使用FindByIdAsync时取消了ASP.Net Core Identity

我有一个小项目，该项目将Asp.Net Core Identity框架与EF Core一起使用。
一个函数调用UserManager.FindByIdAsync(id)并返回正确的对象。但是，它仅在应用程序启动后几分钟起作用。只要服务器繁忙，它就可以正常工作，但是只要应用程序空闲超过1-2分钟，请求就会失败。

它失败并显示:

*OperationCanceledException: The operation was canceled.
System.Threading.CancellationToken.ThrowOperationCanceledException()*

stacktrace看起来像这样:

*System.Threading.CancellationToken.ThrowOperationCanceledException()
Microsoft.AspNetCore.Identity.EntityFrameworkCore.UserStore.FindByIdAsync(string userId, CancellationToken cancellationToken)
Microsoft.AspNetCore.Identity.UserManager.FindByIdAsync(string userId)
MyProject.Areas.Admin.ControllerServices.UserService+<GetUser>d__11.MoveNext() in UserService.cs*

我仍在登录，因为其他页面运行正常。
对EF context.Users.FindAsync(new object[] { id })的简单调用将按预期工作，但是包含FindByIdAsync的下一行将失败。

所有这些在开发环境中都可以完美地工作，当应用程序安装在WS 2008 R2上运行IIS的服务器上时，会发生错误。回收应用程序池将使其重新工作，直到再次空闲几分钟。

我已经注意到，当“连接ID“0HL5E91K33IIQ”之类的行重置时。被记录，然后该应用程序开始失败。在此之前，它可以工作。

FindByIdAsync不是唯一失败的标识函数，许多其他函数也会因相同的错误而失败。

我想念什么？

最佳答案

我会回答我自己的问题，希望这会在将来对其他人有所帮助。

对我而言，这一切都归结为注入(inject)服务的生命周期。UserManager取决于IHttpContextAccessor(这是CancellationToken的来源)，并且当生命周期不匹配时，它的行为会不正确。IHttpContextAccessor被添加为Singleton服务，而UserManager被添加为范围服务。我使用UserManager的服务已添加为Singleton服务。
将其更改为Scoped可以使错误消失。

关于使用FindByIdAsync时取消了ASP.Net Core Identity，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/44430868/