ASP.NET MVC Identity Framework在开发中依赖于FindByEmail调用，但不是实时版本

Question

我们的网站使用MVC和身份框架2.0。在现场网站上（幸运的是）用户现在可以完美登录：

以下是将此工作附加到帐户控制器的登录操作的代码：

public async Task<ActionResult> Login(vmAccountLogin model, string ReturnUrl)
{
    // if problems with model, just redisplay form
    if (!ModelState.IsValid)
    {
        return View(model);
    }


    // hangs on this line
    var user = UserManager.FindByEmail(model.Email);

    // if user not found for this email, abort with no clues
    if (user == null)

当我构建项目并将DLL复制到实时服务器时，它完美地运行。但是......

在我的测试版本上，这会挂在显示的行上。大约十秒钟后，调试跳转到 Dispose 方法。我逐行浏览了web.config文件以检查它们是否相同。我读过很多SO文章，但不认为它们中的任何一个都适用于这个问题。顺便说一下，这是UserManager调用，工作正常：

public ApplicationUserManager UserManager
{
    get
    {
        return _userManager ?? HttpContext.GetOwinContext().GetUserManager<ApplicationUserManager>();
    }
    private set
    {
        _userManager = value;
    }
}

如果我启用.NET符号的调试，它会挂起FindByEmail方法调用。 GetUserManager调用在即时窗口中显示：

?HttpContext.GetOwinContext().GetUserManager<ApplicationUserManager>();
{wiseowl.ApplicationUserManager}
    ClaimsIdentityFactory: {Microsoft.AspNet.Identity.ClaimsIdentityFactory<wiseowl.Models.ApplicationUser, string>}
    DefaultAccountLockoutTimeSpan: {00:05:00}
    EmailService: {wiseowl.EmailService}
    MaxFailedAccessAttemptsBeforeLockout: 5
    PasswordHasher: {Microsoft.AspNet.Identity.PasswordHasher}
    PasswordValidator: {Microsoft.AspNet.Identity.PasswordValidator}
    SmsService: {wiseowl.SmsService}
    Store: {Microsoft.AspNet.Identity.EntityFramework.UserStore<wiseowl.Models.ApplicationUser>}
    SupportsQueryableUsers: true
    SupportsUserClaim: true
    SupportsUserEmail: true
    SupportsUserLockout: true
    SupportsUserLogin: true
    SupportsUserPassword: true
    SupportsUserPhoneNumber: true
    SupportsUserRole: true
    SupportsUserSecurityStamp: true
    SupportsUserTwoFactor: true
    TwoFactorProviders: Count = 2
    UserLockoutEnabledByDefault: true
    UserTokenProvider: {Microsoft.AspNet.Identity.Owin.DataProtectorTokenProvider<wiseowl.Models.ApplicationUser>}
    UserValidator: {Microsoft.AspNet.Identity.UserValidator<wiseowl.Models.ApplicationUser>}
    Users: {System.Data.Entity.DbSet<wiseowl.Models.ApplicationUser>}
    _claimsFactory: {Microsoft.AspNet.Identity.ClaimsIdentityFactory<wiseowl.Models.ApplicationUser, string>}
    _defaultLockout: {00:05:00}
    _disposed: false
    _factors: Count = 2
    _passwordHasher: {Microsoft.AspNet.Identity.PasswordHasher}
    _passwordValidator: {Microsoft.AspNet.Identity.PasswordValidator}
    _userValidator: {Microsoft.AspNet.Identity.UserValidator<wiseowl.Models.ApplicationUser>}

有人有什么建议吗？

Answer 1

到目前为止，测试环境中的挂起看起来像混合了异步和阻塞调用，这可能导致死锁。 FindByEmail是一种扩展方法，用于封装UserManager.FindByEmailAsync。

的异步API调用

UserManagerExtensions.cs中找到的该版本的源代码显示异步调用正在同步执行。

/// <summary>
///     Find a user by email
/// </summary>
/// <param name="manager"></param>
/// <param name="email"></param>
/// <returns></returns>
public static TUser FindByEmail<TUser, TKey>(this UserManager<TUser, TKey> manager, string email)
    where TKey : IEquatable<TKey>
    where TUser : class, IUser<TKey>
{
    if (manager == null)
    {
        throw new ArgumentNullException("manager");
    }
    return AsyncHelper.RunSync(() => manager.FindByEmailAsync(email));
}

我认为在测试环境中运行时会导致死锁（挂起）。不解释为什么它仍然在现场环境中工作。

我建议通过FindByEmailAsync方法尽可能地使代码异步。尽量避免混合异步和阻止呼叫。

public async Task<ActionResult> Login(vmAccountLogin model, string ReturnUrl) {
    // if problems with model, just redisplay form
    if (!ModelState.IsValid) {
        return View(model);
    }

    // hangs on this line
    var user = await UserManager.FindByEmailAsync(model.Email);

    // if user not found for this email, abort with no clues
    if (user == null)

    //...code removed for brevity

除此之外，我还建议确保测试环境正在使用身份数据存储的正确连接字符串。因为等待连接到数据库时挂起也可能是因为超时。