Ohad Meir
Ohad Meir

Reputation: 714

EF migrations claims there were changes in the context while there were none

I'm using Entity Framework Migrations & Code First and recently encountered a very weird problem. The problem was reproduced with versions 4.3.1 and 4.4.

EF thinks that the context was changed while actually it didn't. It happens when I change the path of the solution. for example: If my solution is located in C:\integration\something.sln the migration may work but if now I will change the path to C:\development\something.sln and re-build the solution the migration will throw an exception saying there are pending changes in the database. (Of course without any changes in the source code.

I used IL Disassembler to create a dump of the output assemblies and with BeyondCompare I saw that there are differences. I assume the data is the same but its written in different order...

How EF determines if there were changes in the context? Is it possible that the assembly check-sum comes out different and will cause EF to think that there were changes?

Any ideas are most welcome...

Upvotes: 3

Views: 687

Answers (1)

Ohad Meir
Ohad Meir

Reputation: 714

First, this is not a migration issue - its probably a bug in the Entity Framework's algorithm to check if there are changes in the database.

I had a class hierarchy that contained an abstract class with no properties, making that class not abstract solved the problem.

After gaining some precious debugging experience, I found several ways to solve this issue and each one raised more eyebrows than the one before which makes me very convinced that I fell on a very rare corner case. As I mentioned, I decided to solve by making a class not abstract.

I tried to reproduce the bug in a clean solution so I can send it to Microsoft but until now it didn't really work.

So... to sum things up, if you find yourself with such a problem (very frustrating one), a good tip is to look for abstract classes!

Upvotes: 2

Related Questions