使用Identity 2.0数据库对ASP.NET Core 1.0应用程序进行身份验证

本文介绍了使用Identity 2.0数据库对ASP.NET Core 1.0应用程序进行身份验证的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我正在尝试创建一个新的ASP.NET Core 1.0 Web应用程序，并且希望它使用已经设置的身份验证表.这些表最初是由使用Microsoft.ASPNet.Identity.EntityFramework 2.2.0的ASP.NET 4.6 Web应用程序创建的.

I am trying to a create a new ASP.NET Core 1.0 web application and I want it to use the Authentication tables that I already have set up. These tables were originally created by a ASP.NET 4.6 web application that used Microsoft.ASPNet.Identity.EntityFramework 2.2.0

Microsoft.AspNetCore.Identity.EntityFrameworkCore似乎发生了变化 因为新的Core 1.0应用程序在尝试登录时会引发此错误:

It looks like things have change in Microsoft.AspNetCore.Identity.EntityFrameworkCore because the new Core 1.0 application throws this error when trying to log in:

在处理请求时，数据库操作失败.

A database operation failed while processing the request.

SqlException:无效的列名'NormalizedUserName'. 无效的列名"ConcurrencyStamp". 无效的列名"LockoutEnd". 无效的列名"NormalizedEmail". 无效的列名"NormalizedUserName".

SqlException: Invalid column name 'NormalizedUserName'. Invalid column name 'ConcurrencyStamp'. Invalid column name 'LockoutEnd'. Invalid column name 'NormalizedEmail'. Invalid column name 'NormalizedUserName'.

project.json直接开箱即用，如下所示:

The project.json is straight out of the box and looks like this:

"dependencies": { "Microsoft.NETCore.App": { "version": "1.0.0", "type": "platform" }, "Microsoft.AspNetCore.Authentication.Cookies": "1.0.0", "Microsoft.AspNetCore.Diagnostics": "1.0.0", "Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore": "1.0.0", "Microsoft.AspNetCore.Identity.EntityFrameworkCore": "1.0.0", "Microsoft.AspNetCore.Mvc": "1.0.0", "Microsoft.AspNetCore.Razor.Tools": { "version": "1.0.0-preview2-final", "type": "build" }, "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0", "Microsoft.AspNetCore.Server.Kestrel": "1.0.0", "Microsoft.AspNetCore.StaticFiles": "1.0.0", "Microsoft.EntityFrameworkCore.SqlServer": "1.0.0", "Microsoft.EntityFrameworkCore.SqlServer.Design": { "version": "1.0.0", "type": "build" }, "Microsoft.EntityFrameworkCore.Tools": { "version": "1.0.0-preview2-final", "type": "build" }, "Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0", "Microsoft.Extensions.Configuration.Json": "1.0.0", "Microsoft.Extensions.Configuration.UserSecrets": "1.0.0", "Microsoft.Extensions.Logging": "1.0.0", "Microsoft.Extensions.Logging.Console": "1.0.0", "Microsoft.Extensions.Logging.Debug": "1.0.0", "Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0", "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0", "Microsoft.VisualStudio.Web.CodeGeneration.Tools": { "version": "1.0.0-preview2-final", "type": "build" }, "Microsoft.VisualStudio.Web.CodeGenerators.Mvc": { "version": "1.0.0-preview2-final", "type": "build" }

}，

此外，我没有更改ApplicationDbContext，但在该类中看到了一些有关进行更改以解决此问题的帖子

Also, I have not changed my ApplicationDbContext, but I have seen some posts about making changes to resolve this issue in that class

推荐答案

此SQL迁移脚本使我克服了上述障碍:

This SQL migration script got me over the above hurdle:

Alter Table ASPNETROLES ADD ConcurrencyStamp varchar(255) null, NormalizedName varchar(255) null Drop Table AspNetUserTokens CREATE TABLE [AspNetUserTokens] ( [UserId] NVARCHAR (450) NOT NULL, [LoginProvider] NVARCHAR (450) NOT NULL, [Name] NVARCHAR (450) NOT NULL, [Value] NVARCHAR (MAX) NULL, CONSTRAINT [PK_AspNetUserTokens] PRIMARY KEY CLUSTERED ([UserId] ASC, [LoginProvider] ASC, [Name] ASC) ) Alter Table AspNetUsers Add ConcurrencyStamp varchar(255) null, LockoutEnd DateTime null, NormalizedEmail varchar(255) null, NormalizedUserName varchar(255) null Drop Table [AspNetRoleClaims] CREATE TABLE [AspNetRoleClaims] ( [Id] INT IDENTITY (1, 1) NOT NULL, [ClaimType] NVARCHAR (MAX) NULL, [ClaimValue] NVARCHAR (MAX) NULL, [RoleId] NVARCHAR (128) NOT NULL, CONSTRAINT [PK_AspNetRoleClaims] PRIMARY KEY CLUSTERED ([Id] ASC), CONSTRAINT [FK_AspNetRoleClaims_AspNetRoles_RoleId] FOREIGN KEY ([RoleId]) REFERENCES [dbo].[AspNetRoles] ([Id]) ON DELETE CASCADE ) GO CREATE NONCLUSTERED INDEX [IX_AspNetRoleClaims_RoleId] ON [AspNetRoleClaims]([RoleId] ASC) Alter Table AspNetUserLogins Add ProviderDisplayName varchar(255) null

Microsoft尚未就如何迁移数据库提供大量指导，但这为我解决了上述问题.

There's not been a ton of guidance from Microsoft over how to migrate the database but this fixed the above issue for me.