entity-framework - tutorial - migration script entity framework

enable-migrations en x64 Project obtiene System.BadImageFormatException

Question

Tengo un proyecto configurado para x64 (está usando algunos paquetes de Nuget que son solo de 64 bits). Todo se ejecuta y se implementa bien, pero al intentar ejecutar las enable-migrations de enable-migrations de EF en la Consola del administrador de paquetes, System.BadImageFormatException una System.BadImageFormatException . La excepción completa:

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: he eliminado el nombre del proyecto del mensaje de error, tanto para facilitar la búsqueda en Google como porque es irrelevante para este problema.

Answer 1

Como lo indica el soporte de Microsoft: "la solución es cambiar a AnyCPU o x86 [antes de] generar / ejecutar migraciones y luego volver a intercambiar".

También sugieren: "[refactorizando] el modelo / las migraciones en un proyecto separado que es AnyCPU"

Answer 2

El problema es que el comando enable-migrations parece tener una ruta codificada donde EF busca los archivos DLL construidos de su proyecto en /bin/Debug , sin importar cuál sea la ruta de compilación real. Cuando cambia un proyecto a x64, Visual Studio cambia silenciosamente la ruta de compilación de su proyecto a /bin/x64/Debug , mientras que EF sigue buscando en /bin/Debug . Eso hace que esta vaga System.BadImageFormatException.

Es inofensivo simplemente cambiar la ruta de compilación de su proyecto a /bin/Debug y mágicamente, todo comienza a funcionar como se supone.

El error existe hasta e incluyendo EF 6.1.0. Informe de error publicado .

Actualización : Microsoft ha decidido no molestarse en corregir el error, cerrado como wontfix, porque existe una solución alternativa. Bastante mal comportamiento.

Answer 3

El tema central fue alrededor del x64. En mi caso, estaba tratando de usar la solución de referencia de Azure Mobile Services Todo. En esta solución, hay una solución de Servicios y 2 soluciones de cliente front-end (Windows 8 y Windows Phone).

Al experimentar con la solución, agregué soporte fuera de línea. El soporte sin conexión implementa SQLite, y SQLite requiere configurar la Solución para utilizar x64 o ARM para los respectivos clientes nativos.

Por lo tanto, al cambiar el objetivo de la CPU para resolver el soporte de SQLite, debo haber modificado la CPU x64 en los Servicios y guardarla. Cuando vi mi error de usar x64 para el servicio, cambié de nuevo a Cualquier CPU.

Todo esto lleva a ... la próxima vez que intenté agregar migraciones, mi archivo .csproj para los servicios se "corrompió" según la información de esta publicación. En mi caso, hice el siguiente cambio / actualización en el archivo .csproj del servicio:

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

En mi caso,

<PlatformTarget/> 

Todavía se estableció como x64.

Answer 4

No te confundas como yo:

1. Cambie la plataforma activa a AnyCPU desde el ConfigurationManager (si falta, agregue)
2. Ir a las propiedades del proyecto que contiene el DbContext
3. En la pestaña Crear , cambie el destino de la plataforma a AnyCPU
4. Ejecute el siguiente comando en la Consola del administrador de paquetes : Enable-Migrations -ProjectName ProjectNameThatContainsTheDContext

Answer 5

Vaya a Administrador de IIS> Ver grupo de aplicaciones> Herramienta de aplicación predeterminada> Configuración avanzada ...> Establezca 32 bits en verdadero