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…
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!