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 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 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.
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 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 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.