Code First View Generation Generating Different Hash Values

Topics: EF Power Tools, General
May 13, 2013 at 8:09 AM
Sorry if this is not the correct place for this post but it has been up on the entity framework forum and stackoverflow for over a week and I have not got a response, and I consider this a major issue with Entity Framework.

We are currently developing a system that uses EF 5.0 (Code First) and WCF Data Services for its data access tier. We were experiencing slow initialization of the services and tracked this down to the view generation for our EF contexts, in some cases the views were taking 7 seconds to initialize. After some research we found the posts detailing the use of the EF power tools to pre-generate the views for the contexts in our project. We created a sample project and created the pre-generated views and found some significant speed improvements dropping the startup time by around 2/3rds. However when we have come to use the views in our live code we have found a problem with the view generation in that it creates different HashOverMappingClosure & HashOverAllExtentViews values on every development pc we run the generation on. This is obviously because the view it is generating is different but we cannot understand why this is the case when our development pc's are running off the same virtualized images with the only difference being the hardware they are running on. The above makes the generated views unusable because when the hash validation is run by EF it fails with....

'The mapping and metadata information for EntityContainer '.....' no longer matches the information used to create the pre-generated views'

We have found the posts on the EF codeplex site detailing improvements in this area but this doesnt help us as we locked into version 5.0 of EF because of our dependancy on WCF Data Services. Is there any way we can get this working with version 5.0 by ensuring the hash's are generated in the same way on each pc? We are willing to take a look at the EF source, but we couldnt find version 5.0 on codeplex?

Any help will be gratefully appreciated as we are keen to use the generated views as it makes a big difference to the response times in our application.
May 13, 2013 at 3:08 PM
Edited May 13, 2013 at 4:12 PM
This would indicate that the edmx file you use in the development is different than the one in production. Can you diff the two and see if there are any differences? If you are using CodeFirst then we found a problem that sometimes views generated on a 32-bit machine will not work if the app is run on a 64-bit machine. The issue was that the order members were returned in by reflection might sometimes be different on different architectures. Someone reported that this happens if partial classes are involved. In EF6 the way we calculate the hash ignores order - here is the related work item: https://entityframework.codeplex.com/workitem/816.
May 14, 2013 at 9:58 AM
We're using code first so its not different edmx files causing the problem, also all of our test systems are 32 bit so they are running the same architecture.

We also tried removing the partial classes and consolidating the classes into one but the hashes which were generated were still different. We do use table per hierarchy and table per type inheritance, does this have any bearing on the hashes?

As stated above this may be resolved in EF 6 but we cant upgrade because we use WCF Data Services and this doesnt work with the latest version of EF because the namespaces have changed.

We really need to use the pre-generated views to improve the performance of our application but we seem to be stuck with an unworkable version because we cannot upgrade.

Any suggestions on how we can move forward?
May 14, 2013 at 4:09 PM
You could try troubleshooting it with EdmxWriter.WriteEdmx. Dump the edmx on both machines and compare if there are any differences - this might give you a hint why your views don't work. Also make sure you regenerate your views each time model changes.
May 14, 2013 at 5:25 PM
It looks like its a problem with inherited types. We generated the XML data models using the power tools and compared them on two PC's and the areas where there are differences were on types that we have defined using table per hierarchy. Could this be a similar problem to the partial classes where reflection is returning types in different orders?

If so is there any way we can fix this in EF5?
May 14, 2013 at 7:06 PM
Yes. I think I saw on stackoverflow someone commenting that inheritance can also break views. I don't know of any good workaround for this bug. Using edmx file with Code First may help but is kind anti-CodeFirst. Note that at runtime views are generated once per app domain. Yes it affects the app start time but once the app is started it will never try regenerating views. I am also curious what's different between the two machines. Can it be that you target .NET Framework 4 and one machine has real .NET Framework 4 and the other one has .NET Framework 4.5? (Having said that - Reflection does not guarantee the order in which members are returned - in theory you if you run an app twice on the same machine you members could be returned in different order).