Я наконец взломал его - после небольшой погони за диким гусем, думая, что это из-за разрешений.
Откровение: ИСПОЛЬЗУЙТЕ SQL PROFILER
(Примечание: я недавно понижен с EF6 до EF5)
Используя SQL Profiler, я быстро нашел последний SQL-запрос, выполненный до сообщения об ошибке:
SELECT TOP (1)
[Project1].[C1] AS [C1],
[Project1].[MigrationId] AS [MigrationId],
[Project1].[Model] AS [Model]
FROM ( SELECT
[Extent1].[MigrationId] AS [MigrationId],
[Extent1].[Model] AS [Model],
1 AS [C1]
FROM [dbo].[__MigrationHistory] AS [Extent1]
) AS [Project1]
ORDER BY [Project1].[MigrationId] DESC
Хорошо, посмотрите на это - как-то связано с миграциями. Он смотрит в таблицу __MigrationHistory
- которую я даже не осознал, что он создал (я уже стер Миграции в моем CSPROJ) и очистил ее.
Итак, я извлекаю строки для этой таблицы и вижу, что она связана с конкретной версией продукта (v6).

Я фактически понизил EF6 (который я не собирался устанавливать в первую очередь) до EF5 (который более совместим с лесами) и затем, когда начались проблемы.
Я предполагаю, что столбец Model (<Binary data>)
не имеет обратной совместимости - следовательно, ошибка The provider did not return a ProviderManifest instance
, поскольку он не смог его декодировать.
Мне нечего было терять, я просто полностью стер эту таблицу и запустил Update-Database -Verbose
, а затем снова заработал.
Если вы находитесь в продвинутой среде или уже работаете, то уничтожение этой таблицы может не быть решением, но этот способ позволил мне вернуться к работе.