Thursday, August 14, 2008

Serious Fail of ASP.NET Dynamic Data SP1 with Entity Framework v1 RTM Data Source

Update 8/18/2008: Scott Hunter of the DD Team posted to the Dynamic Data Entity Framework Workaround thread 0f 8/16/2008 a message with a link to the workaround in CodePlex for the "A property with name 'XX.Id' does not exist in metadata for entity type 'XX.XX.XXXX'” exception with the Entity Framework as a data source.

For more information about the workaround, see Workaround for Dynamic Data Entity Framework Posted post of 8/16/2008.

Apparently the DD team tested their SP1 release only with LINQ to SQL as the data source. This is surprising when you consider the emphasis the Data Programmability group is placing on Entity Framework.

I’ve tested Microsoft.Web.DynamicData.dll (the replacement for System.Web.DynamicData.dll) and the revised RegisterContext() method. It fixes the problem for me. The updated version of the DynamicDataWebApp project has been incorporated in a replacement for the file that should be posted at shortly. The DynamicDataWebSite file-system project uses LINQ to SQL as its data source, so it wasn’t affected by the DD team’s gaffe.

In the meantime, you can download the updated code from SkyDrive.

Original Content Starts Here

A reader of my “Generate Web Sites Automatically” cover story for the August 2008 issue of Visual Studio Magazine reported today that the accompanying sample code threw a runtime exception under VS 2008 SP1 when clicking the View Order_Details link of the Orders list page shown below (click image for a full-size capture):

The “A property with the name ‘Order.OrderID’ does not exist in metadata for entity type ‘NorthwindModel.Order_Detail’” runtime error appears as follows (click for full size):

This problem was reported on August 13, 2008 in Dynamic Data SP1 chokes on Northwind and AdventureWorks using ADO.Net Entity Data Model thread or the ASP.NET ASP.NET Dynamic Data forum. According to David Ebbo’s reply on the same date:

There is indeed an issue with the Entity Data Source that is causing this. Here it is described by someone from the Entities team:

"Currently for a (1 : 0..1) relationship, we expose references to the “1” end but we don’t expose the references to the “0..1” end. For ex: consider something like “Person”->”PersonDetails” with a (1 : 0..1) relationship between them:

There will be a property descriptor “Person” on “PersonDetails” entity. However there’ll be no property descriptor called “PersonDetails” on “Person” entity."

We'll see if there are some possible workarounds.  BTW, you mention that you also see this with Northwind.  Specifically, which Northwind table are you seeing this on?

It appears to me that the problem differs from the description above. The multiplicity of the Order:Order_Details relationship is 1:*, and there is no reason for an attempt to read the Order_Details.Order.OrderID value from the associated (1:0..1) EntityReference.

If there aren’t “some possible workarounds” available immediately, this will be a serious blow to the Data Programmability group’s attempt to position the Entity Framework as the preferred data source for new programming frameworks, such as ADO.NET Data Services (Astoria).

In the event there’s no prospect for a timely workaround, I’ll change the data source for the sample projects from Entity Framework to LINQ to SQL and update the sample code accordingly.


Anonymous said...

Can you point me to a good link where I can come up to speed with Entiy.Net, Astoria etc.
I consider myself a C# guru

Roger Jennings (--rj) said...
This comment has been removed by the author.
Roger Jennings (--rj) said...

The best current list of links to new the new ADO.NET and ASP.NET technologies in VS 2008 SP1 is Scott Hanselman's post: Hidden Gems - Not the same old 3.5 SP1 post (

Anonymous said...

Strange issue, Roger. I updated our DD support code to SP1 RTM a few days ago, and they indeed added 1:1 relationship support (which wasn't in the previous iterations), though I think this issue is a case of renaming properties perhaps? OrderID vs. OrderId ? (so it can't find OrderID as it has OrderId ?) The 1:1 relationship addition might have been done a bit hasty, i.e.: it could have caused problems which were unforeseen (as 1:1 relationships are tricky in some cases)

Though DD in general has a problem though at the moment: it lacks a serious filtering system. It now creates combo boxes to filter entities on m:1 related entities (e.g. you look orders and you can filter on customers, employees) which grow really really big if there are a lot of related entities. Like in some Adventureworks tables where the comboboxes contain over 40K rows! I did expect that they had fixed this or at least addressed it a bit in RTM but that wasn't the case. Which I find a bit weird as I reported this issue to them back in april... and they said they were working on this issue back then already...

Anonymous said...

The Dynamic Data Team has published a modified version of their Entity Framework provider that contains a workaround for this issue. You can read more details about it here:

And download it from CodePlex here:

Roger Jennings (--rj) said...

@diego vega,

Thanks for the comment. I updated the post re the workaround on August 16 and then updated the update to include my test of the fix on August 18.

Unknown said...

To solve my problem, i've downloaded the project and got the Microsoft.Web.DynamicData.dll file from it. Then, i added this file to my project, and changed the following Global.asax line:

model.RegisterContext(typeof(MyEntities), new ContextConfiguration() { ScaffoldAllTables = true });

To this:

model.RegisterContext(new Microsoft.Web.DynamicData.EFDataModelProvider(typeof(MyEntities)), new ContextConfiguration() { ScaffoldAllTables = true });

Worked like a charm ... ;)