本文主要是介绍一例附加类型“LMSoft.FrameWork.Identity.ApplicationUser”的实体失败，因为相同类型的其他实体已具有相同的主键值错误的解决，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在使用Microsoft.AspNet.Identity做会员开发时有一个批量修改会员信息的功能。在做的时候出现这样的错误：
附加类型“LMSoft.FrameWork.Identity.ApplicationUser”的实体失败，因为相同类型的其他实体已具有相同的主键值。在使用 "Attach" 方法或者将实体的状态设置为 "Unchanged" 或 "Modified" 时如果图形中的任何实体具有冲突键值，则可能会发生上述行为。这可能是因为某些实体是新的并且尚未接收数据库生成的键值。在此情况下，使用 "Add" 方法或者 "Added" 实体状态跟踪该图形，然后将非新实体的状态相应设置为 "Unchanged" 或 "Modified"。
查了许多资料，并不明白问题出在哪里，又比较了下单独修改一个会员信息的存储程序代码和批量生成的程序代码，也没找到错误的原因。
最后找到一篇博文，博文很长，最后得出的结论是：出现异常的原因，可能是UserManager、RoleManager使用了不同的数据库上下文
我的修改会员信息没有用到RoleManager,但是用到了UserManager.难道是查询的会员信息的语句和更新语句数据库上下文不同？于是进行检查：
查询会员信息语句：
var user = UserManager.FindByIID(i);
这个FindByIID是自定义的一个方法，通过自动增加的IID字段来获取applicationuser对象。这个方法使用的数据库上下文是：
private readonly IdentityDbContext _db = new IdentityDbContext();
这个是自定义的。获取的user对象赋了新值后使用的是updateasync方法。
var result= await UserManager.UpdateAsync(user);
UpdateAsync此方法是vs内置的方法，使用的数据库上下文肯定不是我这个。于是我查了下我修改单个会员信息所使用的查询代码：
var user = UserManager.FindById(model.GID);
这个FindById也是内置的方法。难怪我单独修改会员的页面没有问题，是因为其查询语句和更新语句使用的是同一个数据库上下文。于是我进行修改我的查询语句为下面的代码：
var user = UserManager.Users.FirstOrDefault(m => m.IID == i);
编译运行，这次没问题了。看来问题就是出在这里。被附加修改的数据实体必须和更新语句使用同一个数据库连接，否则就会出问题。
这篇关于一例附加类型“LMSoft.FrameWork.Identity.ApplicationUser”的实体失败，因为相同类型的其他实体已具有相同的主键值错误的解决的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
