EF(MSSQL2016)+xUnit测试更新GENERATE ALWAYS列异常排查

这个异常的核心原因是你手动设置实体状态为Modified的操作，导致EF尝试更新表中所有列，包括那些被数据库标记为GENERATED ALWAYS的自动维护列（比如SysStartTime），而这类列是不允许手动更新的。

为什么正常调试时没报错？ #

在常规调试场景下，当你从当前dbContext查询出dbUser时，EF已经自动开启了对该实体的变更追踪。当你修改LastLoginDate后，EF会精准地只标记这个属性为“已修改”，调用SaveChanges()时只会生成更新LastLoginDate的SQL语句，不会触碰SysStartTime这类自动生成列，所以不会触发数据库的限制。

而你额外添加的dbContext.Entry(dbUser).State = EntityState.Modified其实是画蛇添足的操作：它会强制EF把整个实体标记为“已修改”，但在常规调试中，EF的模型配置（比如你对SysStartTime设置了DatabaseGeneratedOption.Computed）会让EF自动排除这些列，所以最终生成的SQL还是不会包含它们，因此没报错。

为什么xUnit测试中会触发异常？ #

测试场景下可能存在两种导致差异的情况：

• EF追踪状态异常：如果测试环境中，查询dbUser时EF的追踪行为被意外修改（比如某些测试初始化代码全局开启了AsNoTracking），那么修改LastLoginDate后EF不会自动标记属性变更，此时手动设置EntityState.Modified会让EF生成包含所有列的Update语句，包括GENERATED ALWAYS列，触发数据库报错。
• 模型配置不一致：虽然你说测试和生产用了相同的连接字符串，但测试环境的EF模型初始化可能存在差异，导致SysStartTime的DatabaseGeneratedOption配置没有生效，此时手动设置实体状态为Modified会让EF尝试更新这些列。

解决方案 #

直接移除dbContext.Entry(dbUser).State = System.Data.Entity.EntityState.Modified;这行代码即可，原因如下：

• 因为dbUser是从当前dbContext查询出来的，EF默认会追踪它的状态，修改LastLoginDate后EF会自动标记该属性为已修改。
• 移除这行代码后，无论是常规调试还是xUnit测试，EF都会只生成更新LastLoginDate的SQL语句，不会触碰GENERATED ALWAYS列，异常自然消失。

你也可以验证一下：移除该行后，在测试中调用SaveChanges()时，查看EF生成的SQL语句（可以通过EF的日志功能开启），会发现只更新了LastLoginDate和必要的并发列（比如RowVersion），完全不会涉及SysStartTime或SysEndTime。

内容的提问来源于stack exchange，提问作者XzajoX