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

92

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.

Remy
fuente
¿Usó la función "Agregar dependencias implementables" para este proyecto?
ChristiaanV
No, no lo intenté. Pero configuré todo de nuevo y ahora funciona ... No es realmente satisfactorio, pero ...
Remy
Tengo este problema cada vez que reinicio mi máquina y también reinicio Visual Studio. De alguna manera desapareció si limpio y luego reconstruyo la solución.
frostshoxx

Respuestas:

30

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.
Alexander Beletsky
fuente
1
De alguna manera mi proyecto comenzó a funcionar, pero no tengo ni idea de por qué ... Su enfoque parece factible.
Remy
alexanderb: ¿cómo cambio al perfil .NET 4.0? ¿En Visual Studio? ¿Dónde se encuentra la carpeta bin? ¿Es el archivo .csproj el archivo web.config? Thx
WhoAmI
114

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.

Krzysztof
fuente
4
¿Deberían configurarse los ensamblados para copiar localmente con este cambio?
Rasmus Christensen
3
El problema para mí fue que uno de mis paquetes Web Api NuGet tenía una dependencia en System.Net.Http 2.0.0.0 pero mi referencia que tenía era 2.1.10.0 que se estaba enviando a mi carpeta bin.
JustinMichaels
2
Esto es correcto (como dijo Justin Michaels). La dependencia se refiere a 2.0.0.0 pero su referencia de ensamblado es a 2.1.xx Todo lo que necesita para solucionar esto es la redirección de enlace.
Tod Thomson
2
Esta debe marcarse como la respuesta correcta. Supongo que es por eso que todos los demás usuarios están impulsando esta opción. ¡Gracias, Krzysztof!
Blaise
3
El problema probablemente no sea la referencia directa a System.Net.Http, sino una referencia indirecta que se usa en una de las otras bibliotecas a las que hace referencia. Es por eso que configurar la copia local generalmente no solucionará este problema.
Paul Keister
10

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>
Clive
fuente
Hice algo como esto, pero actualicé newVersion a 4.0.0.0 y dejé oldVersion como 0.0.0.0-2.0.0.0
Veritoanimus
2

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.

GeekyMonkey
fuente
1
En realidad, eso es lo que me confunde. Yo uso nuget y tengo esta carpeta. Pero si miro System.Net.Http, tiene la versión 1.0.0.0
Remy
1
¡Así es exactamente como lo arreglé! Ya que todo funcionó a nivel local. Acabo de hacer clic con el botón derecho en la referencia y, en propiedades, lo configuré Copy localcomo verdadero, lo que lo resuelve. más fácil / mejor que jugar con archivos web.config. Simplemente agregue el dll a su carpeta bin.
JP Hellemons
2

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" />
knocte
fuente
1

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
Dunken
fuente
1

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.

StefanoM5
fuente
Para mostrar las etiquetas XML correctamente, formatee el texto como código. Para esto, solo agregue cuatro espacios antes de cada línea.
Artemix
Tnx Artemix, este es mi primer comentario;)
StefanoM5
1

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

Sudhanshu Mishra
fuente
1

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.

Eric Reiss
fuente
1

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.

Rudy Scoggins
fuente
0

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

Lücks
fuente
0

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>
Osama
fuente
0

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

Javier González
fuente
0

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.

Chris Moschini
fuente
0

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.

Rachana
fuente
0

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.

Micaël
fuente
0

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.

mhapps
fuente