To be honest I can't remember (and I'm definitely not going to look). It was pretty early in the development of EF - I understand that this problem no longer exists and lazy loading works fine now.
Which I would totally have understood and forgiven if they'd been honest about it. But all the documentation was lying, except this one tiny bit buried deep in the tech docs. That wasn't the first time I've encountered this phenomenon in Microsoft tech. It seems there's a mis-communication between the documentation team and the actual dev team, and they end up documenting what should happen instead of what actually happens.
You said yourself that the lazy loading actually did work most of the time except for these problem cases, right?
So doesn't that sound more like it might just be an unintentional bug or maybe you had your environment configured differently from what the docs were expecting?
It really sounds to me like you threw the baby out with the bathwater over a small bug, when bugs of a similar magnitude will likely be present on every other platform too (including documentation bugs)
I've never used EF or developed business apps in .NET, but I have used similar technologies like Hibernate in Java and I think you are basically describing standard caveats with any ORM. Lazy loading is often a non-obvious behavior.
If your documentation says in several places that your system does X, but it doesn't, it does Y, then that's lies.
It might be caused by a bug, and what you're documenting is intended behaviour not actual behaviour. But then you need to say that somewhere - something like "We expect the system to do X but we haven't actually tested it so it might not". Not saying that, and instead saying "the system does X" is lying.
And yeah, I stopped using ORMs too :) They just get in the way.
With this definition, every software which has undocumented bugs (i.e. every software) is lying. That doesn't seem useful to me and I don't see how the problem is solved by moving away from EF either.
No, I think there's a difference between undocumented bugs and professional documentation that very clearly documents behaviour that doesn't actually match what the system does.
As others have said, it's a problem that's particularly apparent with Microsoft - it feels disjointed. Like the documentation team read a different spec than the development team.
No, but I do have a longstanding annoyance with the general form of argument in which technologies are dismissed just because they have some weird edge cases. All substantial technologies have weird edge cases.
Which I would totally have understood and forgiven if they'd been honest about it. But all the documentation was lying, except this one tiny bit buried deep in the tech docs. That wasn't the first time I've encountered this phenomenon in Microsoft tech. It seems there's a mis-communication between the documentation team and the actual dev team, and they end up documenting what should happen instead of what actually happens.