No se pudo cargar el archivo o ensamblado System.Net.Http, Versión = 4.0.0.0 con ASP.NET (MVC 4) Web API OData Prerelease

81

Problema

Después de instalar la versión preliminar de Microsoft ASP.NET Web API OData package 5.0.0-rc1 , termino con la siguiente excepción:

No se pudo cargar el archivo o ensamblado 'System.Web.Http, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35' o una de sus dependencias. La definición del manifiesto del ensamblado ubicado no coincide con la referencia del ensamblado. (Excepción de HRESULT: 0x80131040)

Mi proyecto MVC 4 es nuevo y realmente pequeño, no tiene nada de lujos. Me dirijo a .NET framework 4.5

Necesito este paquete nuget para implementar PATCH usando la clase Delta (cuando uso la versión 4.0.0.0 del paquete, la clase Delta no funciona).

¿Cómo puedo arreglar eso?

Mis versiones de System.Web.Http

En GAC tengo la versión 5.0.0.0 de System.Web.Http

gacutil -l System.Web.Http La caché de ensamblados global contiene los siguientes ensamblados: System.Web.Http, Version = 5.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL

En Visual Studio , cuando busco ensamblados, la versión dada de System.Web.Http es 4.0.0.0 (¿Por qué?)

En mi proyecto , la referencia a System.Web.Http

  • Tiene la versión 5.0.0.0
  • Apunta a la carpeta \ lib \ net45 \ del paquete
  • Tiene CopyLocal = verdadero

Cosas que probé

Intenté enlazar la redirección v 4.0.0.0 a 5.0.0.0 en Web.config

<dependentAssembly>
    <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="4.0.0.0-4.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>

Pero me da otra excepción:

El intento del método 'System.Web.Http.GlobalConfiguration..cctor ()' de acceder al campo 'System.Web.Http.GlobalConfiguration.CS $ <> 9__CachedAnonymousMethodDelegate2' falló.

Supongo que la v 4.0.0.0 realmente necesita ser utilizada por el motor principal de Web Api.

Preguntas vinculadas

Error de análisis de código No se pudo cargar el archivo o ensamblado 'System.Net.Http, Version = 2.0.0.0 en MVC4 Web API No se pudo cargar el archivo o ensamblado' System.Net.Http, Version = 2.0.0.0 en MVC4 Web API

asp.net-mvc-4  asp.net-web-api  odata  assembly-resolution 
— Yves M.
fuente
1
Tal vez esta respuesta pueda ayudarlo: stackoverflow.com/a/18700279/795876
— fsenart

Respuestas:

164

Visual Studio 2013 tiene una nueva función para solucionar este problema. Cuando compila la aplicación, debería ver advertencias sobre las diferentes versiones de un ensamblado al que se hace referencia. Haga doble clic en la advertencia para agregar redireccionamientos de enlace de ensamblado al web.config.

Consulte http://msdn.microsoft.com/en-us/library/2fc472t2.aspx para obtener más detalles.

jeff.eynon señala a continuación que debe tener el web.config verificado (si usa el control de fuente TFS) para que VS edite el archivo automáticamente. ¡Gracias por el consejo!

— Jay Douglass
fuente
7
Desearía poder votar esto 10 veces. Que VS hiciera esto automáticamente fue bueno. ¡Gracias por el consejo!
— Bob Horn
4
Desafortunadamente, no siempre funciona. De hecho, diría que la mayoría de las veces, hacer doble clic en esta advertencia no hace nada.
— Trevor de Koekkoek
3
Debe tener la configuración de la web / aplicación que se está modificando. Por alguna razón, VS no parece dispuesto a revisar el archivo por usted en este caso.
— jeff.eynon
39

Lo hice funcionar actualizando el paquete WebApi a la versión preliminar usando nuget:

PM> Microsoft.AspNet.WebApi -Pre

Para forzar el proyecto usando la última versión de WebApi, fueron necesarias algunas modificaciones en la raíz Web.config:

1) Versión de páginas web de 2.0.0.0 a 3.0.0.0

<appSettings>
    <add key="webpages:Version" value="3.0.0.0" />
</appSettings>

2) Enlace de redireccionamiento a 5.0.0.0 para System.Web.Http y System.Net.Http.Formatting

<dependentAssembly>
    <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
<dependentAssembly>
    <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>

Creo que eso es todo

PD: Solución muy inspirada en WebAPI OData 5.0 Beta: acceder a GlobalConfiguration arroja un error de seguridad

— Yves M.
fuente
3
esto funcionó para mí: enfrenté este mismo problema cuando instalé el último paquete de API web CORS debido a la dependencia de system.net.http actualizada.
— sandeep talabathula
1
you rock man, muchas gracias. En mi caso, la configuración web no se actualizó mediante la restauración de nuget, lo hice manualmente después de la implementación.
— Leandro
Del mismo modo, esto obtiene un +1 porque cuando VS no hace esto por usted, necesita esta respuesta para poder hacer que el enlace funcione usted mismo.
— Michael Blackburn
11

Encontré el mismo problema y lo resolví estableciendo CopyLocal en verdadero para las siguientes bibliotecas:

System.Web.Http.dll
System.Web.Http.WebHost.dll
System.Net.Http.Formatting.dll

Debo agregar que uso MVC4 y NET 4

— Bronek
fuente
1
esto también lo resolvió para mí; sin embargo, realmente me gustaría saber qué significa esto realmente.
— serup
11

Experimenté este problema cuando intenté actualizar un proyecto Hot Towel desde la plantilla del proyecto y cuando creé un proyecto vacío e instalé HotTowel a través de nuget en VS 2012 a partir del 23/10/2013.

Para solucionarlo, actualicé a través de Nuget los paquetes Web Api Web Host y Web API a 5.0, la versión actual en NuGet en este momento (23/10/2013).

Luego agregué las instrucciones de enlace:

<dependentAssembly>
  <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
<dependentAssembly>
  <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
— Kevin LaBranche
fuente
8

O puede hacer esto desde NuGet Package Manager Console

 Install-Package Microsoft.AspNet.WebApi -Version 5.0.0

Y luego podrá agregar la referencia a System.Web.Http.WebHost 5.0

— Sameer Alibhai
fuente
4

Elimine System.Web.Http y System.Net.Http.Formatting de sus referencias y agregue referencias nuevamente navegando a su carpeta bin (donde fueron copiadas por nuget) Ahora la versión del archivo dice 5.0.0.0

— JJ_Coder4Hire
fuente
1

Este error apareció varias veces en varios proyectos diferentes.

Lo que finalmente descubrí es que cuando iba a compilar, ya había una copia del ensamblaje binario system.web.mvc en mi carpeta bin.

Para solucionar este problema, haga clic derecho en el ensamblaje en la lista de referencias y seleccione "propiedades". Compruebe si esta es la última versión en la propiedad "Versión". Si es así, cambie "Copiar local" a verdadero.

Esto asegurará que la versión a la que se hace referencia en su proyecto sea la versión que terminará en su carpeta de binarios.

Si aún recibe el error, intente ejecutar nuGet para obtener la última versión, luego intente lo mencionado anteriormente nuevamente.

Buena suerte, ¡este error es un fastidio!

— user1628627
fuente
1

Me enfrenté al mismo error. Cuando instalé Unity Framework for Dependency Injection, se agregaron las nuevas referencias de Http y HttpFormatter en mi configuración. Así que aquí están los pasos que seguí.

Ejecuté el siguiente comando en la consola del administrador de paquetes nuGet: PM> Install-Package Microsoft.ASPNet.WebAPI -pre

Y se agregó una referencia física a la dll con la versión 5.0

— Chandra Prakash Soni
fuente
1

resuelvo a través de nuget. el primero que instale nuget. el segundo que usa.
la siguiente ilustración:

tercero: compruebe si esta es la última versión mirando la propiedad "Versión".

El último: verifica que el proyecto tenga la última versión nuevamente.

— Nguyễn Thị Nữ
fuente
0

Me enfrenté al mismo tipo de problema y seguí los pasos a continuación para resolverlo

Vaya a Herramientas -> Administrador de paquetes de biblioteca -> Consola del administrador de paquetes y ejecute el siguiente comando

Paquete de instalación Microsoft.ASPNet.WebAPI -pre

— Santu Ghosh
fuente
0

Después de modificar las referencias en el Web.configarchivo como se mencionó anteriormente, resolvimos las referencias.

Estaba enfrentando un problema similar.

Para nosotros tenemos referencia Microsoft.Data.Edm.dlly OData.dlly otros conjuntos de archivos de programa:

C:\Program Files (x86)\Microsoft WCF Data Services\5.0
                          \bin\.NETFramework\Microsoft.Data.Edm.dll

y 

C:\Program Files (x86)\Microsoft WCF Data Services\5.0
                        \bin\.NETFramework\Microsoft.Data.OData.dll

y la versión fue 5.6.4 .

Una vez que cambio la referencia de ambos ensamblajes a C:\....Project\packages\Microsoft.Data.Edm.5.6.0, se resolvió el problema

— Gaurav Gupta
fuente
0

Entré en el administrador de paquetes nuget y actualicé mis paquetes. Ahora funciona. El principal que actualicé fue Microsoft.AspNet.WebApi.Core. Es posible que deba hacer esto con ambos proyectos para sincronizar las referencias adecuadas.

— Exzile
fuente
0

Si se produce este problema, consulte web.config en la siguiente sección

La siguiente sección proporciona la versión de la dll particular utilizada

después de verificar esta sección en web.config, abra el explorador de soluciones y seleccione la referencia en el árbol del proyecto como se muestra. Explorador de soluciones-> Referencia

Después de expandir la referencia, busque la dll que causó el error. Haga clic derecho en la referencia de dll y verifique la versión como se muestra en la imagen de arriba.

Si tanto la versión de config dll como la dll referenciada son diferentes, obtendría esta excepción. Asegúrese de que ambos sean de la misma versión, lo que ayudaría.

— user3235808
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.