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


141

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>

Respuestas:


129

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.


2
El Copy Localya es cierto. ¿Extrañamente muestra que Runtime Versiones v4.0.30319 en lugar de v5?
ca9163d9

44
¿Sabes lo que pasó aquí? Había estado funcionando bien durante 18 meses cuando esto saltó y me mordió.
Glenn Gordon

2
Esto solucionó el problema para mí ¡Gracias! Pero me parece extraño que tengamos que incluir bibliotecas de framework en nuestros proyectos (en mi caso, no Azure sino un servidor IIS). ¿Alguien sabe si se trata de ejecutar algunas actualizaciones para que ya no tengamos que incluirlas?
edgarpetrauskas

1
Mini complemento, ya que me llevó una eternidad encontrar una copia local: en VS2013, abre el nodo "referencias" en el proyecto y hace clic con el botón derecho-> propiedades en la biblioteca en la que desea configurar "copiar local".
ArtHare

66
Si Copy Local ya está configurado en true y no puede actualizar WebApi debido a las dependencias, existe ese truco para configurar Copy Local en false, compilar, luego configure Copiar Local nuevamente en true y build. No sé por qué funciona esto.
DeeArgee

90

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 .


Por favor, evite las respuestas de solo enlaces ... en lugar de
eso

3
La ejecución del comando Update-Package resolvió el problema, mientras que ninguna de las otras sugerencias funcionó. ¡Gracias por la respuesta!
DigiOz Multimedia

La mejor solución al problema.
Festim Cahani

Respuesta perfecta, gracias!
Apolo

3
Esta solución también funcionó para mí. Estoy bastante seguro de que esto ha sido causado por la funcionalidad 'Eliminar ensamblados no utilizados' de ReSharper. Eliminar ensamblajes no utilizados a veces elimina ciegamente ensamblajes sin verificar el contenido del paquete NuGet.
Joe King

54

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


gracias esto fue útil ¿Sabes por qué estos archivos no solo estarían en GAC? ¿Es porque diferentes sitios podrían estar usando diferentes marcos de dotnet, etc.?
dellyjm

Como recuerdo, este problema ha sucedido desde que Microsoft aplicó soluciones críticas en esa área (supongo que en System.Web / ASP NET / MVC). Supongo que estos espacios de nombres no están en GAC (por lo que no están en ensamblados NET nativos) sino en rutas separadas de Visual Studio o MVC.
Bronek

Esto resolvió el problema en mi VPS (este no es solo un problema azul)
Evilripper

Esto funcionó para mí (aunque no estoy usando Azure). Estaba moviendo un proyecto de un entorno de marco .net 4.5 a uno 4.0 y obtuve este problema al final de todo.
TheQ

1
Según la sugerencia anterior de DeeArgee, ya tenía COPIA LOCAL = verdadero para los 3 de estos dll. Pero esta sugerencia finalmente resolvió el problema: "Si Copy Local ya está configurado en verdadero, existe ese truco para configurar Copy Local en falso, compilar, luego configurar Copiar Local nuevamente en verdadero y compilar. No sé por qué esto funciona. - DeeArgee 19 de noviembre de 2015 a las 17:16
Debbie A

34

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.


2
usted es maravilloso. funcionó como un encanto en mvc5. Gracias
David Graça

2
¡Gracias, también trabajé para mí +1, la persona que hizo esta pregunta debería marcar esto como la respuesta!
Ray

O simplemente agregue el Microsoft.AspNet.WebApi.WebHostpaquete a través de nuget.
Optimax

15

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.


¡Trabajó para mi! Buena esa.
Dr Schizo

Esta es la única solución aquí que funcionó para mí. Supongo que había alguna otra versión antigua de un dll que hizo tropezar las cosas. ¡Gracias!
Ohad Schneider

10

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.


lo mismo aquí, esto es exactamente lo que se necesitaba.
pabloelustondo

1
Probablemente porque es la misma solución descrita en varias otras respuestas un año antes.
Chad

6

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.


2

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>

2

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 .


1

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>

0

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


0

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.


0

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.


0

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>

0

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ó.

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.