enable-migrations in x64 Project ottiene System.BadImageFormatException

Question

Ho un progetto impostato su x64 (sta utilizzando alcuni pacchetti Nuget solo a 64 bit). Tutto gira e distribuisce bene, ma provare a eseguire l'EF enable-migrations nella console di Gestione pacchetti mi dà un System.BadImageFormatException. L'eccezione completo:

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. 

Nota: ho rimosso il nome del progetto dal messaggio di errore, sia per rendere questo più facile da Google e perché è irrilevante a questo problema.

Answer 1

Il problema è che il comando enable-migrations sembra avere un percorso hard-coded in cui EF cerca DLL create del progetto a /bin/Debug, indipendentemente dal percorso di generazione effettivo. Quando si modifica un progetto in x64, Visual Studio modifica in modo silenzioso il percorso di generazione del progetto su /bin/x64/Debug - mentre EF continua a cercare in /bin/Debug. Ciò causa questa vaga System.BadImageFormatException.

È innocuo cambiare il percorso di costruzione del progetto in /bin/Debug e magicamente, tutto inizia a funzionare come dovrebbe.

Errore fino a EF 6.1.0 incluso. Bug report posted.

Aggiornamento: Microsoft ha deciso di non preoccuparsi di correggere il bug, chiuso come wontfix, perché esiste una soluzione alternativa. Cattivo comportamento.

Answer 2

Il problema principale era intorno al x64. Nel mio scenario, stavo cercando di utilizzare la soluzione di riferimento Todo di Servizi mobili di Azure. In questa soluzione, vi è una soluzione di servizi e 2 soluzioni di front-end client (Windows 8 e Windows Phone).

Nella sperimentazione della soluzione, ho aggiunto il supporto offline. Il supporto offline implementa SQLite e SQLite richiede la configurazione della soluzione per utilizzare x64 o ARM per i rispettivi client nativi.

Quindi, cambiando l'obiettivo della CPU per risolvere il supporto SQLite, devo aver modificato CPU x64 sui Servizi e salvato. Quando ho visto il mio errore nell'uso di x64 per il servizio, sono passato a qualsiasi CPU.

Tutto questo porta a ... quando ho tentato di aggiungere nuove migrazioni, il mio file .csproj per i servizi era "danneggiato" in base alle informazioni in questo post. Nel mio caso ho fatto la seguente modifica/aggiornamento nel file Csproj del servizio:

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

Nel mio caso,

<PlatformTarget/> 

era ancora impostato come x64.

Answer 3

Come affermato dal supporto Microsoft: "la soluzione alternativa è di passare a AnyCPU o x86 [prima di] generare/eseguire migrazioni e quindi eseguire lo swap back".

Essi inoltre suggeriscono: "[refactoring] il modello/migrazioni in un progetto separato che è AnyCPU"

Answer 4

Vai alla Gestione IIS> Vista Application Pool> Impostazioni strumento> Advance applicazione di default ...> Imposta 32 bit true