Reputation: 714
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
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