Enable-migrations в x64 Project получает System.BadImageFormatException

У меня есть проект, установленный в x64 (он использует некоторые пакеты Nuget, которые только 64-разрядные). Все работает и развертывается нормально, но при попытке запустить EF enable-migrations в консоли диспетчера пакетов мне присваивается System.BadImageFormatException. Полное исключение:

PM> enable-migrations
System.BadImageFormatException: Could not load file or assembly  or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)
   at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
   at System.Reflection.Assembly.Load(String assemblyString)
   at System.Data.Entity.Migrations.Design.ToolingFacade.BaseRunner.LoadAssembly(String name)
   at System.Data.Entity.Migrations.Design.ToolingFacade.GetContextTypeRunner.Run()
   at System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate)
   at System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate)
   at System.Data.Entity.Migrations.Design.ToolingFacade.Run(BaseRunner runner)
   at System.Data.Entity.Migrations.Design.ToolingFacade.GetContextType(String contextTypeName)
   at System.Data.Entity.Migrations.EnableMigrationsCommand.FindContextToEnable(String contextTypeName)
   at System.Data.Entity.Migrations.EnableMigrationsCommand.<>c__DisplayClass2.<.ctor>b__0()
   at System.Data.Entity.Migrations.MigrationsDomainCommand.Execute(Action command)

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Could not load file or assembly  or one of its dependencies. An attempt was made to load a program with an incorrect format.

Примечание. Я удалил имя проекта из сообщения об ошибке, чтобы сделать это проще для google и потому что это не имеет отношения к этой проблеме.

Ответ 1

Проблема заключается в том, что команда enable-migrations имеет жесткий код, где EF ищет встроенные библиотеки DLL вашего проекта в /bin/Debug, независимо от того, что представляет собой фактический путь сборки. Когда вы меняете проект на x64, Visual Studio спокойно меняет путь построения проекта на /bin/x64/Debug - в то время как EF продолжает искать в /bin/Debug. Это вызывает это неопределенное System.BadImageFormatException.

Безвредно просто изменить свой путь построения проекта до /bin/Debug и волшебным образом, все начинает работать так, как оно должно было.

Ошибка до EF 6.1.0 включительно. Опубликован отчет об ошибках.

Обновить. Microsoft решила не беспокоиться об исправлении ошибки, закрытой как wontfix, поскольку существует обходное решение. Довольно плохое поведение.

Ответ 2

Как указано в поддержке Microsoft: "Обходной путь заключается в замене на AnyCPU или x86 [перед вами] генерации/запуска миграции, а затем свопинга".

Они также предлагают: "[рефакторинг] модели/миграции в отдельный проект, который является AnyCPU"

Ответ 3

Основная проблема была вокруг x64. В моем сценарии я пытался использовать ссылочное решение Azure Mobile Services Todo. В этом решении есть решение "Службы" и 2 решения для конечных пользователей (Windows 8 и Windows Phone).

В эксперименте с решением я добавил автономную поддержку. Автономная поддержка реализует SQLite, а SQLite требует настройки решения для использования x64 или ARM для соответствующих собственных клиентов.

Таким образом, чтобы изменить цель процессора для решения поддержки SQLite, я должен был изменить CPU x64 в Сервисах и сохранить. Когда я увидел свою ошибку использования x64 для службы, я вернулся к любому процессору.

Это все приводит... когда я попытался добавить миграции, мой файл .csproj для служб был "поврежден" на основе информации в этом сообщении. В моем случае я сделал следующее изменение/обновление в файле .csproj службы:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <PlatformTarget>AnyCPU</PlatformTarget>
</PropertyGroup>

В моем случае

<PlatformTarget/>

все еще задан как x64.

Ответ 4

Перейдите в диспетчер IIS > Просмотреть пул приложений > Инструмент приложения по умолчанию > Предварительные настройки... > Установите 32 бита в true