This issue has been reported in our UserVoice site (currently with 11 votes):
https://data.uservoice.com/forums/72025-entity-framework-feature-suggestions/suggestions/2746981-allow-ignoring-issues-with-dropping-non-existent-f
Apparently the problem is that in Code First and Migrations we assume that foreign key constraints always have corresponding indexes. This is always true when the database is created using the Migrations DDL pipeline, but not necessarily true when using Code First to map to an existing database (e.g. using the reverse engineering functionality in the PowerTools).
People with this setup can workaround the issue by manually removing the calls to DropIndex in their Down steps, but it can become quite annoying.
Brice and I discussed this briefly and we believe the simpler solution would be to add existence checks to each command produced by DropIndex.
Comments: verified, closing
https://data.uservoice.com/forums/72025-entity-framework-feature-suggestions/suggestions/2746981-allow-ignoring-issues-with-dropping-non-existent-f
Apparently the problem is that in Code First and Migrations we assume that foreign key constraints always have corresponding indexes. This is always true when the database is created using the Migrations DDL pipeline, but not necessarily true when using Code First to map to an existing database (e.g. using the reverse engineering functionality in the PowerTools).
People with this setup can workaround the issue by manually removing the calls to DropIndex in their Down steps, but it can become quite annoying.
Brice and I discussed this briefly and we believe the simpler solution would be to add existence checks to each command produced by DropIndex.
Comments: verified, closing