Entity Framework 4.1 The model backing the context has changed since the database was created, immediately after creating DB?

The error you see means that model hash stored in EdmMetadata table is different then model hash computed from model in the application. Because you are running database creation from different application (your dev. Application) it is possible that those two differs.

Simple advice here is: don't use different application for database creation and instead let your main application to create database (either automatically or for example with some admin interface).

The error you see means that model hash stored in EdmMetadata table is different then model hash computed from model in the application. Because you are running database creation from different application (your dev. Application) it is possible that those two differs.

Simple advice here is: don't use different application for database creation and instead let your main application to create database (either automatically or for example with some admin interface). As anothe option you should be able to turn off this check completely by removing convention responsible for these checks: modelBuilder.Conventions.Remove(); Model hash computation is dependent on current entities in your application (any simple change result in different model hash) and on database server versions / manifest. For example model deployed on SQL server 2005 and 2008 will have different model hash (Express vs. Full or 2008 vs. 2008 R2 should not result in different model hash).

We've got a different OS version on the desktop and server, and we also have a couple of different versions of SQL Server because I'm using SQL Express locally but not on UAT. If its just a fact of life that these platform differences will cause a different EdmMetadata hash, I am happy to simply disable the hash creation/checking by removing the convention. Thanks!

– DaveBeta Dec 19 '11 at 17:25.

This can happen due to reflection ordering differences across different platforms. To verify, you can use the EdmxWriter API to compare the EDMX from both environments. If any of the tables have different column ordering, then this is the issue.To workaround, you can change the way your test database gets updated such that it is updated from your test server rather than your local box.

We are going to fix this issue in the next release.

In the code-first approach, the SSDL is generated during the execution of the code. One of the informations included in the generated SSDL is the name of the provider used in the DbConnection. As you said, you're connecting to different databases engines, so you must use two different providers.

This completly changes the output of the hashing function. The below code was extracted from the EntityFramework assembly: using (XmlWriter writer = XmlWriter. Create(output, settings)) { new SsdlSerializer().

Serialize(database, providerInfo. ProviderInvariantName, providerInfo. ProviderManifestToken, writer); } Please mark this as an answer, so I can receive my bounty.

:).

I'm seeing a difference between debug and release, not from the provider changing – JarrettV Dec 23 '11 at 5:07 Although this doesn't answer my question, it does answer the original question. Here is your bounty. – JarrettV Dec 23 '11 at 5:10.

It appears the SHA256CryptoService used can throw a PlatformNotSupportedException which causes it to fallback to another method. msdn.microsoft.com/en-us/library/system.... // System.Data.Entity.Internal. CodeFirstCachedMetadataWorkspace private static SHA256 GetSha256HashAlgorithm() { SHA256 result; try { result = new SHA256CryptoServiceProvider(); } catch (PlatformNotSupportedException) { result = new SHA256Managed(); } return result; } You may be able to test this by using reflection to invoke the following 2 (internal/private) methods on each server.

MetaDataWorkspace. ToMetadataWorkspace(DbDatabaseMapping, Action) CodeFirstCachedMetadataWorkspace. ComputeSha256Hash(string xml).

It falls back to a managed version that should produce same result. – JarrettV Dec 23 '11 at 5:08.

This might help and the link to Scott G blog will sure be a solution to your problem check this question link Edit 1: this is the link to Scott G blog Edit 2: You may also check this if you use a database first on integration server Edit 3: This is a more detailed answer like the one from Scott G.

Entity Framework code first creates a table called EdmMetadata. It keeps a hash of your current model. Once you run the application EF checks if the model being used is the same as the model that the db 'knows about'.

If you want to perform database migration, I suggest you use EF Code first migrations though it's still an alpha. If you don't want to use migrations you can either: handle the schema change manually - that means moving the content of the EdmMetadata table to the test server along with all the changes or set the db initializer to DropCreateDatabaseIfModelChanges (or better something derived from it and use the Seed() method to write the initial data). To set the initialzer either call Database.SetInitializer() on application start or use the appSettings.

1 Thanks for that. My mystery was more around the fact that I have 2 application servers which as far as I can tell are identical - certainly the DLLs are identical, and yet they both seem to think the DB created by the other is "different". I have found that just by deleting the EdmMetadata table I can suppress the error and both applications seem to be working with the same database happily.

This seems wrong! – DaveBeta Nov 29 '11 at 18:40 i'm having a similar problem at deploy time, a simple recompile and redeploy of the dll (absolutely no changes) and it fixes the problem – JarrettV Dec 15 '11 at 22:14.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.