No se pudo cargar el archivo o ensamblado 'System.Net.Http, Version = 2.0.0.0 en MVC4 Web API

Tengo un problema un poco extraño.
Desarrollé una aplicación con MVC 4 y la nueva API web y funciona bien a nivel local. Instalé MVC4 en el servidor e implementé la aplicación. Ahora me sale el siguiente error:

No se pudo cargar el archivo o ensamblado 'System.Net.Http, Version = 2.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)

Descripción: se produjo una excepción no controlada durante la ejecución de la solicitud web actual. Revise el seguimiento de la pila para obtener más información sobre el error y dónde se originó.

Curiosamente, la versión de System.Net.Http que tengo localmente en mi carpeta de paquete o en la carpeta ASP.NET MVC 4 \ Assemblies es 1.0.0.0. De hecho, eliminé la referencia a System.Net.Http de mi proyecto, pero sigo recibiendo el mismo mensaje. Estoy un poco confundido acerca de dónde obtiene la referencia 2.0.0.0 y por qué funcionaría localmente pero no en el servidor.

Mirando las dependencias nuget:

Las bibliotecas principales de API WEb ASP.NET (Beta) dependen de System.Net.Http.Formatting.
Y System.Net.Http.Formatting depende de System.Net.Http.
Supongo que de ahí viene esto. Pero tengo la versión 2.0.20126.16343 de este paquete instalada, es solo que el dll dentro tiene la versión 1.0.0.0

¿Me estoy perdiendo de algo?

ACTUALIZAR:

Esta es una sub-aplicación de otra aplicación ASP.NET, pero la otra todavía está basada en WebForms. Entonces, algo se está estropeando. Pero si hago una limpieza debajo de la sección de ensamblaje en web.config, ya ni siquiera encuentra la aplicación.

Tuve el mismo problema con la implementación de mi aplicación en appharbor. El problema es que aún no es compatible con .NET 4.5. Lo que hice.

1. Cambié mi proyecto al perfil .NET 4.0.
2. Paquete NuGet de API web desinstalado.
3. Se instaló el paquete NuGet de API web (Beta) nuevamente.
4. Verificó que el archivo .csproj contiene TODOS los ensamblados referenciados, por lo que siempre lo tomará de la carpeta Bin, en lugar de GAC.

Tuve el mismo error al implementar la aplicación web previamente convertida (de .NET 4.5 a 4.0) en IIS 6.0.

En la sección de tiempo de ejecución de web.config que encontré

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>

a la que me he cambiado

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

Ahora funciona a las mil maravillas.

El mío trabajó con:

Tenga en cuenta la redirección de 1-4 a 2.0

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a"   culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

En la carpeta de referencias de su proyecto debería haber una referencia a este dll, y la versión debería ser 2.0.0.0. Asegúrese de que esté configurado en Copiar local = verdadero. Y luego asegúrese de que llegue a la carpeta bin de su aplicación de servidor.

Esta es una de las bibliotecas que ahora administra nuget. Así que abre Nuget y asegúrate de que todo esté actualizado. Y en el directorio de paquetes de proyectos, el archivo debería estar aquí: \packages\System.Net.Http.2.0.20126.16343\lib\net40

También puede intentar crear una nueva aplicación MVC4 y ver si el archivo aparece para esa.

En mi caso, lo arreglé de una manera mucho más fácil, solo le doy un HintPath a la referencia al paquete nuget:

     <Reference Include="System.Data.Entity" />
     <Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>
     </Reference>
     <Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>
     </Reference>
     <Reference Include="System.Numerics" />
     <Reference Include="System.Security" />

En mi caso, agregué involuntariamente una dependencia a System.Net.Http versión 2.1.10.0 a través de NuGet. No pude deshacerme de él en el Administrador de paquetes NuGet (porque otros paquetes parecían depender de él). Sin embargo, esos paquetes no dependen de esta versión en particular. Esto es lo que hice para deshacerme de él (también puede usar la consola NuGet en su lugar (usando el parámetro –force):

• Cambie la versión de Microsoft.Net.Http en packages.config de 2.1.10.0 a 2.0.0.0
• Desinstalar BCL Portability Pack en NuGet Package Manager
• Deshazte manualmente de las bibliotecas dependientes (System.Net.Http. * Que tienen la versión 2.1.10.0)
• Agregue una referencia a System.Net.Http 2.0.0.0

En la configuración del archivo eliminé el ensamblaje dependiente:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>

Ahora funciona bien.

Estaba enfrentando este problema en un servidor de prueba (Windows 2008 R2) que supuestamente estaba "listo" para la implementación;)

La pista fue que cuando verifiqué las versiones de System.net entre mi máquina DEV y el servidor de implementación, no coincidían.

Se corrigió usando los pasos a continuación:

1. Descargado el instalador independiente de .NET Framework 4.5 desde AQUÍ

2. Ejecutó el instalador en la máquina de implementación

Después de la instalación del marco, el servidor quería reiniciar, así que lo hizo y ¡volla! ¡¡Estamos listos para ir !!

Estamos usando VS 2013, creamos una nueva API web MVC 4 y tuvimos un problema con system.net.http.dll no es la versión correcta cuando se construyó en nuestro servidor TeamCity, pero funciona bien en nuestras máquinas de desarrollo locales que tienen VS 2013 instalado.

Finalmente determinamos el problema.

Al crear una nueva API web MVC 4 y elegir el marco 4.0 en la creación del proyecto, encontramos que se estaba colocando la versión correcta del paquete NuGet para DLL: .. \ packages \ Microsoft.Net.Http.2.0.20710.0 \ lib \ net40 \ System.Net.Http.dll

Sin embargo, el archivo .csproj para este proyecto decía que la ruta para este archivo system.net.http.dll es: .. \ packages \ Microsoft.Net.Http.2.0.30506.0 \ lib \ net40 \ System.Net.Http.dll

Entonces, cuando se intenta la compilación, falla en esta diferencia de ruta, pero se encuentra la versión de marco correcta del archivo en otro lugar de la máquina del desarrollador, pero no en nuestro servidor de compilación TeamCity.

Hasta ahora, esta es la única diferencia que encontramos. Cambiar la ruta en el archivo .csproj y construir en la máquina Dev local con VS2013 todavía funciona find.

Verificar eso en el control de versiones y tener nuestro servidor de compilación TeamCity (sin VS 2013 instalado localmente) ahora encuentra la versión correcta de .dll en su carpeta de paquete NuGet para la solución y se compila con éxito en lugar de buscar otra versión de system.net.http .dll y encontrar una versión más nueva que no coincida con el marco, lo que provoca fallas de compilación.

No estoy seguro si esto ayuda.

Verifique la ruta del archivo de su proyecto para la DLL y asegúrese de que coincida con la ruta de la carpeta del paquete para la DLL.

Simplemente simplificando las otras respuestas para lo que funcionó para mí.

Fui al administrador de NuGet, desinstalé los paquetes relacionados (en mi caso, "Bibliotecas cliente de Microsoft ASP.NET Web API 2.1" y "Json.NET") y los reinstalé. Solo tomó unos pocos clics.

Cierre el proyecto, ábralo de nuevo. Luego, Clean Solution + Build. Funciona para mi

Para la versión 2.2.15.0, hice esto:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.2.15.0"/>
</dependentAssembly>

¡Tuve exactamente el mismo problema! Eché un vistazo a mi pestaña Advertencias en VS y noté que uno de mis paquetes nuget hacía referencia INDIRECTAMENTE a .NETFramework Versión 4.5.0.0. Tuve que desinstalar este paquete y luego reinstalar la versión 4.0, pero asegúrese de especificar las versiones del paquete que admiten 4.0 (creo que volverá a 4.5 por defecto si no especifica al instalar el paquete). ¡Espero que esto ayude!

Tuvimos esto sucediendo en un servidor después de la implementación. Fue causado por:

A) Los archivos antiguos en la carpeta bin todavía están colgados y deberían haber sido eliminados

o

B) No tener acceso de lectura a la carpeta para el usuario de Application Pool Identity.

En otras palabras, para nosotros, esto se resolvió arreglando los permisos en las carpetas del sitio, borrando la carpeta bin y volviendo a implementar.

Tuve el mismo problema con Gembox.spreadsheet.dll versión 31.

"No se pudo cargar el archivo o ensamblado 'GemBox.Spreadsheet, Version = 39.3.30.1095, Culture = neutral, PublicKeyToken = b1b72c69714d4847' 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 ) "

Probé casi todo de estos artículos y ninguno funcionó. Simplemente se solucionó con un simple paso.

Intenté crear proyectos individuales que básicamente configuraban la referencia de versión correcta al dll y el error desapareció por completo de la solución.

Vaya a un problema similar y la directiva mencionada en muchos comentarios funcionó bien

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>

Sin embargo, debe asegurarse de que la cobertura de la versión anterior sea lo suficientemente alta; de lo contrario, es posible que las versiones más nuevas no se redirijan a la versión específica que necesita y la ubicación con esa referencia más nueva no funcionará correctamente ya que la referencia anterior ya está en el directorio bin.

Para este error (y similar), vale la pena pasar por NuGet Consolidate (Solución> Administrar paquetes NuGet ...) para asegurarse de que las mismas versiones de componentes a las que se hace referencia sean consistentes en cada biblioteca de clases a la que se hace referencia en la solución, ya que incluso una versión un poco más antigua puede tener dependencias en otros componentes antiguos. Es fácil de usar junto con las actualizaciones y puede ahorrar mucho dolor.

Esto me resolvió este problema y diría que es imprescindible familiarizarse con si está creando bibliotecas auxiliares que también hacen referencia a MVC u otros componentes NuGet basados ​​en la web.