Given a POCO model and Code First, after setting a foreign key property on an instance that has an associated navigation property, fix-up is supposed to occur during DetectChanges. If code causes another navigation property to be lazy-loaded on that instance then the fix-up does not occur.<br /><br />This appears to be a bug in DetectChanges. From what I can tell this issue exists in all versions of EF since 4.1.<br /><br />The attached solution demonstrates the problem.
Comments: Thank you for your response. If I may, I would like to add some weight to the priority of the issue. As the repro shows, the behavior occurs even when an unrelated navigation property is lazy-loaded. Therefore if an arbitrary Load() is introduced into an application, a bug might be introduced on seemingly unrelated behavior. In fact, this is exactly how my team came to investigate the problem and produce the repro. To pick up on your point, yes, I think it is reasonable to expect that an eventual DetectChanges() will ultimately resolve the situation. It still isn't clear why the Load() causes DetectChanges() to fail to fix-up the associated navigation property.
Comments: Thank you for your response. If I may, I would like to add some weight to the priority of the issue. As the repro shows, the behavior occurs even when an unrelated navigation property is lazy-loaded. Therefore if an arbitrary Load() is introduced into an application, a bug might be introduced on seemingly unrelated behavior. In fact, this is exactly how my team came to investigate the problem and produce the repro. To pick up on your point, yes, I think it is reasonable to expect that an eventual DetectChanges() will ultimately resolve the situation. It still isn't clear why the Load() causes DetectChanges() to fail to fix-up the associated navigation property.