в первом сценарии, где вы изменили первую модель кода, прежде чем вы пошли и изменили базу данных вручную, ответ должен открыть консоль диспетчера пакетов (Nuget) и ввести:

update-database -verbose

Except-потому что в этом случае вы удаляете столбец, это сообщит, что он собирается удалить что-то, и он ничего не удалит, если вы явно не скажете, что все в порядке. Итак, вы набираете:

update-database -f -verbose

теперь это удалит столбец, который у вас был в вашей модели. -verbose говорит, чтобы показать вам SQL, который он работает. Если вы боитесь просто позволить ему удалять вещи и скорее проверять SQL перед его запуском, используйте:

update-database-F-script

это вместо этого сбросит SQL в скрипт, который вы можете просмотреть, и запустить вручную самостоятельно.

в случае, когда вы пошли дальше и удалили столбец в базе данных вручную, теперь у вас есть более сложный сценарий на руках; таблица EdmMetadata, описанная в другом ответе здесь содержится хэш всей базы данных, которая теперь не соответствует самой базе данных. Вы можете запустить ручной SQL, чтобы вернуть БД так, как ожидает Entity Framework (так, как это было до того, как вы вручную изменили его, что возвращает его в соответствие с хэшем), проверив, что у вас было раньше и как выглядит ваша БД в настоящее время.

если это невозможно, вы теперь находитесь в самой уродливой части кода Entity Framework. Вам нужно устранить хэш-таблицу и реконструировать БД в файлах кода.

имя хэш-таблицы зависит от версии EF. В более старом EF4, о котором вы спрашивали, он называется EdmMetadata. В более новой версии EF5 он называется __MigrationHistory (в системных таблицах базы данных, если вы ищете в SQL Server Management Studio). Тебе нужно его стереть.

хорошая новость на втором шаге, обратное проектирование БД в код, заключается в том, что Microsoft выпустила инструмент в бета-версию, которая сделает это для вы.

Walk-through обратн-проектируя db, и электроинструменты EF

вы можете пропустить многие из первых шагов, так как они просто настраивают БД и добавляют к нему какую-то ерунду, чтобы они могли продемонстрировать, что вам нужно сделать: реверсивный инженер БД.

обновление:

также можно использовать ручную миграцию для работы вокруг этого сценария. Сделайте резервную копию БД, затем запустите:

add-migration WhateverYouWantToCallThis

изменения для миграции db EF, которые необходимо запустить, появятся в сгенерированных командах C#. Теперь вам нужно возиться с ними, чтобы обойти проблемы с тем, что он пытается сделать (например, пытается удалить столбцы, которые уже были удалены), и поставить на место вещи, которые ему понадобятся в будущем (например, добавление таблицы, которую вы все еще имеете в своей модели, но вы вручную удалили в своей БД).

как только вы добавили это и запустите update-database -f, код EF сначала будет просто примите на веру, что вы обновили базу данных так, как она должна быть, и обновите ее хэш на основе конечного результата. Если вы внесли правильные изменения, Теперь вы можете продолжить миграцию как обычно. Если это по-прежнему вызывает ошибки, вы можете скопировать команды ручного переноса и удалить их, восстановить БД из резервной копии, добавить перенос вручную и повторить попытку. В худшем случае вы прибегаете к шагу обратной инженерии выше.