Closest thing I could find was this question: EF code migration in reference dll coming through nuget
Similar to that post, we have a package that uses EF 6 to write some cross-reference records. I recently modified the package which modified the schema of the table used by EF. Added the migration, etc, and re-deployed the Package. All good so far.
I've referenced this Nuget package in two different solutions. In one solution, the package did not exist yet so I added it, built, deployed (both using Team City) to Azure. For that solution, there were no pre-existing migrations and therefor no __MigrationHistory table. Once the code hit the xref service it happily created the table and the __MigrationHistory. The table and history all have the correct columns and the full migration history... So far, so good.
In the second solution, the package already existed so I simply updated it. What I expected to happen is when this code called the xref service it would also run the migration, update the column name, and insert the __MigrationHistory record. But, alas, all I get in my logs is "The model backing the 'DatabaseDef' context has changed since the database was created..."
Nowhere in either solution do we use any SetInitializer (code nor config). Both solutions have references to EF in the same places. The only difference is that for the "one that worked" I was actually running through the debugger when it hit the xref service code. I have not tried the other solution running via debugger and cannot think why that would matter, but stranger things have happened. I also have a request in with our Ops team to see if the Team City deployment turns on the code-first migrations during deployment in some instances.
Questions:
- Any ideas why one would work and not the other?
- in the "Xref Nuget Package", where would I put an initializer (if at all)? There is no App_Start or global.asax in there... just an assembly doing its' thing to write the xref records.
- Anything else I'm overlooking?
