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

web forms c# (17)

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

Tengo un problema extraño.
Desarrollé una aplicación con MVC 4 y la nueva API web y funciona perfectamente a nivel local. Instalé MVC4 en el servidor e implementé la aplicación. Ahora recibo 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 ensamblaje ubicado no coincide con la referencia de ensamblaje. (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 la carpeta de mi 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:

ASP.NET WEb API Core Libraries (Beta) depende 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 la dll en su interior tiene la versión 1.0.0.0

¿Me estoy perdiendo de algo?

ACTUALIZAR:

Esta es una subaplicación de otra aplicación ASP.NET, pero la otra todavía se basa en WebForms. Entonces, algo se está arruinando. Pero si hago una limpieza debajo de la sección de ensamblaje en el web.config, si ya no encuentra la aplicación.

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

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 debe haber una referencia a este dll, y la versión debe ser 2.0.0.0. Asegúrese de que esté configurado en Copiar local = verdadero. Y luego asegúrese de que encuentre su camino hacia la carpeta bin de la aplicación de su 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 debe estar aquí: /packages/System.Net.Http.2.0.20126.16343/lib/net40

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

En la configuración de archivo eliminé el ensamblado dependiente:

Ahora funciona bien.

En mi caso, involuntariamente agregué una dependencia a System.Net.Http versión 2.1.10.0 a través de NuGet. No pude deshacerme de él en NuGet Package Manager (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 (usando el parámetro -force):

Cambiar 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
Deshacerse 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 mi caso, lo arreglé de una manera mucho más fácil, simplemente dale una 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" />

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

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

Solucionado usando los pasos a continuación:

Descargué .NET Framework 4.5 Instalador independiente desde HERE
Corrió el instalador en la máquina de despliegue

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

Estamos utilizando VS 2013, creamos una nueva API web MVC 4 y tuvimos un problema con el sistema.net.http.dll no siendo la versión correcta cuando se compiló en nuestro servidor TeamCity, pero funciona bien en nuestras máquinas desarrolladoras locales que tienen VS 2013 instalado

Finalmente determinamos el problema.

Al crear una nueva API web de MVC 4 y elegir el framework 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 dijo 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

Por lo tanto, cuando se intenta construir se produce un error en esta diferencia de ruta, pero se encuentra la versión de estructura correcta del archivo en otro lugar en la máquina del desarrollador, pero no en nuestro servidor de compilación de TeamCity.

Hasta ahora esta es la única diferencia que encontramos. El cambio de la ruta en el archivo .csproj y la construcción en la máquina Dev local con VS2013 todavía funciona.

Al comprobar el control de la versión y tener nuestro servidor de compilación TeamCity (sin VS 2013 instalado localmente) ahora se encuentra la versión correcta de .dll en su carpeta de paquete NuGet para la solución y 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 concuerde con el marco, lo que provoca fallas de compilación.

No estoy seguro si esto ayuda.

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

Para este error (y similar) vale la pena visitar NuGet Consolidate (Solution> Manage NuGet Packages ...) para asegurar que las mismas versiones de componentes referenciadas sean consistentes en cada biblioteca de clase referenciada en la solución, ya que incluso una versión ligeramente anterior puede tener dependencias en otros componentes más antiguos. Es fácil de usar junto con Actualizaciones y puede ahorrar mucho dolor.

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

Para la versión 2.2.15.0, hice esto:

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

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

Tuve el mismo error al implementar una 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, he encontrado

que he cambiado a

<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 como encanto.

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

"No se pudo cargar el archivo o el ensamblado ''GemBox.Spreadsheet, Version = 39.3.30.1095, Culture = neutral, PublicKeyToken = b1b72c69714d4847'' o una de sus dependencias. La definición del manifiesto del ensamblaje ubicado no coincide con la referencia del ensamblado. (Excepción de HRESULT: 0x80131040 ) "

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

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

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

Cambié mi proyecto al perfil .NET 4.0.
Paquete desinstalado de API web NuGet.
Se instaló el paquete Web API (Beta) NuGet nuevamente.
Verificó que el archivo .csproj contenga TODOS los ensamblados a los que se hace referencia, por lo que siempre lo tomará de la carpeta Bin, en lugar de GAC.

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

A) Archivos viejos en la carpeta bin que todavía deberían estar borrados

B) No tener acceso de lectura a la carpeta para el usuario de identidad de grupo de aplicaciones.

En otras palabras, para nosotros esto se resolvió mediante la fijación de permisos en las carpetas del sitio y eliminando la carpeta bin y la redistribución.

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

Aunque debe asegurarse de que la versión anterior sea lo suficientemente alta, las versiones más recientes pueden no redirigirse a la versión específica que necesita y la ubicación con esa nueva referencia no funcionará correctamente, ya que la referencia anterior ya está en el directorio bin.