0

I'm using Asp.Net Identity 2.0.1.

If i copy a database from one development environment to another i get the following error. When i login to my application ().

The Model backing the 'ApplicationDbContext' context has changed since the database was created.....

This is two seperate machines (machine1 and machine2) and the database connections on both are correct, however on the development environment(machine1) where the identitymodel was first generated there are no problems. But on machine2 i get the above error. (My ApplicationDbInitializer is set to CreateDatabaseIfNotExists rather than DropCreateDatabaseIfModelChanges)

Does Identity use the MAC address when defining the Model? And if so is there a way to workaround this?

Tim
  • 7,401
  • 13
  • 61
  • 102
  • this link would be helpful : http://stackoverflow.com/questions/21751402/get-public-ip-address-lan-ip-address-mac-address-of-clients-machine-in-mvc-4 – Kumar Manish May 06 '14 at 07:47
  • @KumarManish - He does not need to know how to get the MAC address, he wants to know if ASP.NET Identity uses the MAC address to determine if it needs to create a new database. – Kevin Junghans May 06 '14 at 12:44
  • 1
    ASP.NET Identity does not look at the MAC address. I do not believe this is an ASP.NET Identity issue, just an EF issue code-first. ASP.NET Identity 2.0 uses EF 6.1, which may behave differently. Take a look at these QA's on this issue and see if they help. http://stackoverflow.com/questions/22408608/the-model-backing-the-applicationdbcontext-context-has-changed-since-the-datab http://stackoverflow.com/questions/3600175/the-model-backing-the-database-context-has-changed-since-the-database-was-crea – Kevin Junghans May 06 '14 at 12:47
  • @KevinJunghans thanks for the advice, are my below assumptions true, each version of EF will invalidate codefirst contexts? – Tim May 06 '14 at 15:27

1 Answers1

0

After some more investigation I realized my assumptions were incorrect. the versions of the entityframework package differed on the two machines. One was using EntityFramework.6.1.1-alpha1-30211 and the other EntityFramework.6.1.1-alpha1-30429. i spotted this in the _MigrationHistory table, I tried changing the ProductVersion field in the _MigrationHistory table on machine2 to match its version of EntityFramework but this didn't work, so I rolled the referenced version back and it worked.

Strange behaviour however. It implies minor versions or patches of EntityFramework will require rebuilds/changes to codefirst databases?

Tim
  • 7,401
  • 13
  • 61
  • 102