c# - asp - No se pudo cargar el archivo o ensamblado ''Microsoft.Data.Edm''

c# asp net (9)

Acabo de tener este mismo problema en mi servidor de compilación y al verificar el resultado de compilación noté lo siguiente:

Copiando archivo de "C: / Archivos de programa (x86) / Microsoft WCF Data Services / 5.6 / bin.NETFramework / Microsoft.Data.Edm.dll" a "bin / Microsoft.Data.Edm.dll".

Parece que hay algo instalado en el servidor de compilación que no está en mi máquina, así que necesito rastrearlo.

Estamos utilizando el paquete Windows Azure Storage NuGet versión 4.1.0, esto tiene una dependencia en Microsoft.Data.OData y también ha agregado ese paquete que tiene el DLL de Microsoft.Data.Edm. Cuando construimos y ejecutamos la aplicación, ocasionalmente recibimos el siguiente error:

Could not load file or assembly ''Microsoft.Data.Edm'' or one of its dependencies. The located assembly''s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Tenemos el siguiente redireccionamiento vinculante en web.config y también lo hemos verificado, y esta es la única versión de Microsoft.Data.Edm a la que hacen referencia los proyectos en la solución.

<dependentAssembly> <assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-5.6.1.0" newVersion="5.6.1.0" /> </dependentAssembly>

A veces, cuando miro en la carpeta bin encuentro que la versión dll de Microsoft.Data.Edm es v 5.6.0. He revisado todos los proyectos y no puedo encontrar una referencia a Microsoft.Data.Edm excepto con el cliente de almacenamiento y definitivamente es 5.6.1.

¿Cuál es la mejor manera de probar de dónde viene la versión 5.6.0? Cuando obtenemos este error, eliminamos las carpetas bin y obj y lo reconstruimos, y luego funciona bien, la versión 5.6.1 está allí y todo funciona, pero finalmente vuelve a suceder.

EDITAR:

Nos hemos actualizado nuevamente a todas las versiones más recientes de NuGet y todavía no tuvimos suerte. Ejecuté una herramienta que muestra las siguientes dependencias:

Possible conflicts for Microsoft.Data.Edm: Microsoft.Data.OData references Microsoft.Data.Edm, Version=5.6.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 Microsoft.Data.Services.Client references Microsoft.Data.Edm, Version=5.6.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 Microsoft.WindowsAzure.Storage references Microsoft.Data.Edm, Version=5.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 Possible conflicts for Microsoft.Data.OData: Microsoft.Data.Services.Client references Microsoft.Data.OData, Version=5.6.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 Microsoft.WindowsAzure.Storage references Microsoft.Data.OData, Version=5.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

Lo que no entiendo es que tenemos configurados los redireccionamientos de aplicaciones, pero en algún momento se copia la versión 2.6.0 y, a veces, la versión 2.6.2. ¿Alguien sabe por qué esto estaría sucediendo, nunca tuvo este problema antes?

Aquí hay algunas cosas que puedes probar:

Verifique su evento Post Build para asegurarse de que ningún archivo Microsoft.Data.Edm.dll se esté copiando manualmente a la carpeta bin.
Asegúrese de que otros paquetes no tengan dependencia de Microsoft.Data.Edm 5.6.1. Una manera fácil de hacerlo es mirando sus archivos package.config.
Si su código está en control de fuente, asegúrese de que nadie revise la carpeta bin. Me sorprende cuánta gente no conoce esta regla básica.
Desinstale los paquetes de WindowsAzure.Storage y Microsoft.Data.Edm. Luego, vuelva a instalar y asegúrese de instalar solo la versión estable.

HTH.

Esto se resolvió con éxito al cerrar y volver a abrir Visual Studio.

Me encontré con un caso similar hoy, en mi situación, la compilación siempre copia una versión antigua dll a la carpeta de depuración, la razón es que mi proyecto no hace referencia a este dll directamente, ref referencia otro proyecto que refiere este dll.
Entonces, cuando compile, mi proyecto encontrará una versión anterior de GAC u otro lugar.
Lo resolví por referencia explícita este dll en el proyecto desde la ubicación correcta.
Me gusta esto:

<Reference Include="Microsoft.Data.Services.Client, Version=5.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>../packages/Microsoft.Data.Services.Client.5.6.1/lib/net40/Microsoft.Data.Services.Client.dll</HintPath> </Reference>

Para mí, tuve que desinstalar el paquete WindowsAzure.MobileServices.Backend.Entity NuGet, que elimina muchos ensambles, incluido Microsoft.Data.Edm. Y luego simplemente lo reinstalé y milagrosamente, ¡funcionó!

Esto fue en mi proyecto Azure Mobile Services WebApi, por lo que necesitaba funcionar, y afortunadamente ahora sí.

Espero que esto ayude.

Probablemente sea un problema de ruta virtual en IIS (creo que este ensamblado se cargó primero al inicio de la aplicación).

Obtuve el mismo problema cuando inicio dos proyectos desde diferentes ubicaciones en el disco pero con las mismas rutas virtuales.

La resolución es eliminar esta ruta de IIS, restablecer el proceso de IIS y crear una ruta virtual nuevamente desde VS.

Tuve el mismo mensaje de error pero mi problema no estaba relacionado con ningún producto de Azure. En mi caso, actualicé OData de la versión 3 a la 4 y me parece que Nuget dejó redireccionamientos vinculantes para dll obsoletos. En realidad, había tres en total, Microsoft.Data.Edm, Microsoft.Data.OData y System.Spatial.

Mi solución fue eliminar los redireccionamientos de enlace obsoletos. También debe quitar el archivo dll antiguo que se encuentra en la carpeta bin si el proceso de compilación no.

Una cosa que a veces parece resolver este problema para los miembros de mi equipo es cerrar todas las instancias de Visual Studio, eliminar el contenido del directorio de paquetes, volver a abrir Visual Studio y luego restaurar paquetes y reconstruir. Sin embargo, esto no siempre funciona.

Pudimos rastrear el problema en una de nuestras máquinas al identificar el proyecto problemático al aumentar la verbosidad de la salida de compilación de Visual Studio:

Luego, buscamos el resultado e identificamos el proyecto objetivo que era problemático buscando "Microsoft.Data.Edm". Notamos que parecía tener una dependencia indirecta a Microsoft.Data.Edm, pero notamos que el ensamblado no se incluyó explícitamente como un paquete para ese proyecto. Entonces, usando la consola del paquete Nuget, apuntamos al proyecto y ejecutamos: Install-Package Microsoft.Data.Edm que resolvió el problema.

Lo encontré !!
dentro de su archivo app.config, cambie la versión de bindingredirect .
Haga que el elemento bindingredirect haga referencia a la versión de la que se queja la excepción, y la excepción desaparecerá.
explicación:
Probablemente el archivo app.config y el conjunto de referencia del proyecto no se sincronizaron, lo que provocó el error.

<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-5.6.4.0" newVersion="5.6.4.0" /> </dependentAssembly> </assemblyBinding> </runtime>