I always love pushing something out that fails miserably and randomly. Especially when using straight Microsoft technologies. It seems these folks don’t eat their own dog food, or we wouldn’t encounter this crap.
Anyway, it took quite a while to figure out the resolution to this issue, but it all lies in the fact that their control is “trying” to be intelligent, and really only needed a little direction.
Let me explain, when the EntityDataSource loads, it looks for the Context. Where may you ask? Well, it actually uses reflection and attempts to load all types from the assembly to resolve the entities. If there is any error in this at all, it blows up. There are a number of reasons this can fail. Dependency mismatches, bad references, and other things that may not break your application but break this feature.
How can I fix this? I am sure you are asking this right now. “Damn it Brian, Get to the freaking point and the fix!” Fine.
It’s pretty simple.
Set this property on the EntityDataSource in your .aspx file. ContextTypeName .
The value? Well, the full namespace and class of your context. Example. Seekford.Data.MyEntityContext
More detailed example:
<asp:EntityDataSource … ContextTypeName="Seekford.Data.MyEntityContext" />
I spent the last hour beating my deciding on which way to destroy my computer, as I battled why my Telerik RadGrid was failing to show the filter data set from my EntityDataSource. (Yes, lazy using these visual controls, but for reports they work well and easy)
Turns out, I had Filtering ON on the data grid. Apparently that disregards the WHERE filter on the data source. Well, that’s a pile of crap.
Anyway, turn off grid filtering or provide your data some other way to the data grid.
Hopefully this saves you time.
I spent about 3 hours cursing up a storm over some data binding I was doing using the EntityDataSource against my Entity Framework context. I was feeling lazy and using the declarative data sources to bind against my grid for some automatic operations. So, should be easy right? Slap on the data source, bind to the grid, add the other data source for the lookups and bind that to the column.
So why was my column always showing the wrong value? Hmm….It was always the first value in the list? hmm…So I thought my grid was defective and went down the route of beating it up. The kicker was I could edit the record, and the newly set value would go into the database. It would never reflect on the grid though. This was rediculously annoying.
I finally gave up and created a new data source and ran my own Linq on the context to pull the objects. Thats when the Ah HA! moment came. I typed my INCLUDE off the context to pull the relationships in.
WAIT! You tell me. Wasn’t that on the data source setup wizard screen when you said pick all the properties? NO. No it isn’t. All the relationships are missing as selectable items on that screen. I guess the EntityDataSource is not usable in these scenarios then, right?
Wrong. After banging your head on the wall a few more times, you gingerly go to the properties window of the EntityDataSource object you created. You delicately go to the Include property and type in the name of the property.
What a pile of crap! I spend 3 hours and multiple rewrites to figure out I could have typed the 8 characters in on the property window and been good to go.
Well, it all works now. I just wish that option would have been in the wizard. If I am going the lazy route with declarative bindings, I want to be able to go full lazy.