No se pudo cargar el archivo o ensamblado System.Web.Http.WebHost después de publicado en el sitio web de Azure

Creé un proyecto web y funciona bien en Visual Studio. Sin embargo, recibí el siguiente error después de publicarlo en azurewebsites. ¿Qué puede causar el problema?

No se pudo cargar el archivo o ensamblado 'System.Web.Http.WebHost, Version = 5.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35' o una de sus dependencias. La definición de 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ó en el código.

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

Error de fuente:

Se generó una excepción no controlada durante la ejecución de la solicitud web actual. La información sobre el origen y la ubicación de la excepción se puede identificar utilizando el seguimiento de la pila de excepciones a continuación.

Rastreo de carga de ensamblaje: la siguiente información puede ser útil para determinar por qué no se pudo cargar el ensamblado 'System.Web.Http.WebHost, Version = 5.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35'.

WRN: el registro de enlace de ensamblado está APAGADO. Para habilitar el registro de fallas de enlace de ensamblaje, establezca el valor de registro [HKLM \ Software \ Microsoft \ Fusion! EnableLog] (DWORD) en 1. Nota: Hay algunas penalizaciones de rendimiento asociadas con el registro de falla de enlace de ensamblaje. Para desactivar esta función, elimine el valor de registro [HKLM \ Software \ Microsoft \ Fusion! EnableLog].

Lo siguiente es parte del archivo web.config.

  <system.web>
    <customErrors mode="Off"/>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" />
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login" timeout="2880" />
    </authentication>
    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Optimization" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
  <handlers>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers></system.webServer>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.1.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.1.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-1.5.2.14234" newVersion="1.5.2.14234" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="EntityFramework" publicKeyToken="b77a5c561934e089" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

los dll falta en el (entorno implementado) publicada. Esa es la razón por la que está trabajando en el local, es decir, Visual Studio, pero no en el entorno del sitio web de Azure.

Simplemente realice Copy Local = truelas propiedades para el ensamblado ( System.Web.Http.WebHost ) y luego realice una nueva implementación, debería funcionar bien.

Si obtiene el error similar, es decir, falta algún otro ensamblaje, haga que ese ensamblaje sea copylocal = true y vuelva a implementar, repita esto de forma iterativa, si no está seguro de sus dependencias.

Si todavía está buscando una respuesta, intente revisar este hilo de preguntas . Me ayudó a resolver un problema similar.

editar: La solución que me ayudó fue ejecutar Update-Package Microsoft.AspNet.WebApi -reinstalldesde el administrador de paquetes NugGet, como lo sugirió Pathoschild. Luego tuve que eliminar mi archivo .suo y reiniciar VS, como lo sugirió Sergey Osypchuk en este hilo .

Encontré el mismo problema y lo resolví estableciéndolo CopyLocalen 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

Para mí trabajé agregando la siguiente sección al web.configarchivo:

<configuration>
...
    <runtime>
    ...
        <dependentAssembly>
            <assemblyIdentity name="System.Web.Http.WebHost" publicKeyToken="31bf3856ad364e35" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-5.1.0.0" newVersion="5.1.0.0" />
        </dependentAssembly>
    ...
    </runtime>
...
</configuration>

Este ejemplo representa MVC 5.1. Espero que ayude a alguien a resolver tal problema.

Para mí, comenzó a funcionar después de seleccionar "Eliminar archivos adicionales en el destino" en las opciones de publicación de archivos en la configuración del cuadro de diálogo de publicación.

Falta el dll en el publicado (entorno implementado). Esa es la razón por la que está trabajando en el local, es decir, Visual Studio, pero no en el entorno del sitio web de Azure.

Simplemente haga Copy Local = true en las propiedades del ensamblado (System.Web.Http.WebHost) y luego realice una nueva implementación, debería funcionar bien.

Estoy usando vs2012 y creo que la actualización KB2781514 cambió algunas configuraciones. Todo mi System.Web.Http en mi proyecto MVC4 cambió a falso y sigo recibiendo este mensaje. Había cambiado la All file in this projectpropiedad en publicar pero no funciona. Finalmente, tengo que cambiar Copy Local = trueuno por uno y resolví este problema.

Recibí el mismo error y cambié mi versión de 4 a 3 y se solucionó:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <!-- Ensure correct version of MVC -->
    <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35"/>
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0"/>
    </dependentAssembly>
</assemblyBinding>

Tuve el mismo problema en mi aplicación.

System.web.http.webhost not found.

Solo necesita copiar el system.web.http.webhostarchivo de su proyecto principal que ejecuta en Visual Studio y pegarlo en su bindirectorio de proyecto publicado .

Después de esto, puede mostrar el mismo error, pero se puede cambiar el nombre del directorio system.web.http. Siga el mismo procedimiento que el anterior. Funcionará después de cargar todos los archivos. Esto debido al paquete nuget en Visual Studio que descargan de Internet pero en el servidor no puede descargarlo.

Puede encontrar este archivo en el bindirectorio de su proyecto .

Esto me sucedió en VS2013 (Actualización 5) /ASP.NET 4.5, bajo el tipo de proyecto "Aplicación web" que incluye MVC y Web API 2. Se produjo un error justo después de crear el proyecto y antes de agregar cualquier código. Agregar la siguiente configuración me lo soluciona. Después de resolver el problema "System.Web.Helpers", aparecieron otros dos errores similares para "System.Web.Mvc" y "System.Web.WebPages".

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.2.3.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>

Me faltaban varias DLL. Incluso si los copiara manualmente en el directorio la próxima vez que publique, desaparecerían. Cada uno ya estaba configurado para Copiar localmente en VS. La solución para mí fue configurar cada uno para Copiar Localmente falso, guardar, compilar y luego configurar cada uno para copiar localmente verdadero. Esta vez cuando publiqué todas las DLL publicadas correctamente. Extraño

Si tiene varios proyectos en su solución y uno de sus proyectos no se puede generar debido a este error, asegúrese de haber instalado el paquete Nuget WebApi Core en ese proyecto. Simplemente agregar una referencia al System.Web.Http no ayuda, necesita instalar el paquete nuget correcto en ese proyecto.

Tenía varios proyectos en mi solución y WebApi Core ya estaba instalado en otro proyecto. Hice referencia al ensamblado System.Web.Http haciendo clic derecho y marcando el ensamblaje de la lista y no funcionó en Azure, aunque localmente se construiría bien. Tuve que eliminar la referencia manual y agregar el paquete Nuget de WebApi Core a cada proyecto que necesitaba la referencia de ensamblaje.

En el caso de que "Copiar local" ya sea Verdadero, a veces creo que funciona si elimina los archivos donde se ha publicado y vuelve a publicar.

Por ejemplo, si está utilizando IIS, elimine los sitios web y el contenido del directorio en el que están publicados y vuelva a publicar.

Es posible que haya versiones anteriores de los archivos en el destino, por lo que para asegurarse de que no esté usando versiones anteriores, elimine todo antes de volver a publicar.

Eliminé la siguiente entrada de web.config y funcionó para mí.

<dependentAssembly>
                <assemblyIdentity name="System.Web.Http.WebHost" culture="neutral" publicKeyToken="31BF3856AD364E35" />
                <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="5.2.6.0" />
            </dependentAssembly>

Asegúrese de que la versión del paquete sea igual en toda la solución. Acabo de degradar y actualizar el Microsoft.AspNet.Mvcpaquete en toda la solución y el problema se resolvió.