Não foi possível carregar o arquivo ou assembly System.Web.Http.WebHost depois de publicado no site do Azure

Eu criei um projeto web e ele roda bem no Visual studio. No entanto, recebi o seguinte erro depois de publicado em azurewebsites. O que pode causar o problema?

Não foi possível carregar o arquivo ou assembly 'System.Web.Http.WebHost, Versão = 5.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35' ou uma de suas dependências. A definição de manifesto da montagem localizada não corresponde à referência da montagem. (Exceção de HRESULT: 0x80131040)

Descrição: ocorreu uma exceção não tratada durante a execução da solicitação da web atual. Revise o rastreamento de pilha para obter mais informações sobre o erro e onde ele se originou no código.

Detalhes da exceção: System.IO.FileLoadException: Não foi possível carregar o arquivo ou assembly 'System.Web.Http.WebHost, Versão = 5.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35' ou uma de suas dependências. A definição de manifesto da montagem localizada não corresponde à referência da montagem. (Exceção de HRESULT: 0x80131040)

Erro de origem:

Uma exceção não tratada foi gerada durante a execução da solicitação da web atual. Informações sobre a origem e o local da exceção podem ser identificadas usando o rastreamento da pilha de exceções abaixo.

Rastreio de Carregamento de Montagem: As seguintes informações podem ser úteis para determinar por que o assembly 'System.Web.Http.WebHost, Versão = 5.0.0.0, Culture = Neutral, PublicKeyToken = 31bf3856ad364e35' não pôde ser carregado.

WRN: O log de ligação da montagem está desativado. Para habilitar o log de falha de ligação de montagem, defina o valor do Registro [HKLM \ Software \ Microsoft \ Fusion! EnableLog] (DWORD) como 1. Nota: Há alguma penalidade de desempenho associada ao log de falha de ligação de montagem. Para desativar esse recurso, remova o valor do registro [HKLM \ Software \ Microsoft \ Fusion! EnableLog].

A seguir, parte do arquivo 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>

A dllestá ausente no (ambiente implantado) publicada. Essa é a razão pela qual ele está funcionando no local, ou seja, Visual Studio, mas não no Ambiente de Site do Azure.

Basta fazer Copy Local = truenas propriedades da montagem ( System.Web.Http.WebHost ) e, em seguida, fazer uma reimplementação, pois deve funcionar bem.

Se você receber um erro semelhante, isto é, falta algum outro assembly, faça com que ele seja copylocal = true e reimplemente, repita-o iterativamente - se você não tiver certeza de suas dependências.

Se você ainda estiver procurando uma resposta, tente verificar este tópico de pergunta . Isso me ajudou a resolver um problema semelhante.

edit: A solução que me ajudou foi executar a Update-Package Microsoft.AspNet.WebApi -reinstallpartir do gerenciador de pacotes NugGet, conforme sugerido por Pathoschild. Eu tive que excluir meu arquivo .suo e reiniciar o VS, conforme sugerido por Sergey Osypchuk neste tópico .

Encontrei o mesmo problema e o resolvi definindo CopyLocaltrue para as seguintes bibliotecas:

System.Web.Http.dll
System.Web.Http.WebHost.dll
System.Net.Http.Formatting.dll

Devo acrescentar que uso MVC4 e NET 4

Para mim, trabalhou adicionando a seguinte seção ao web.configarquivo:

<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 exemplo significa MVC 5.1. Espero que ajude alguém a resolver esse problema.

Para mim, começou a funcionar depois de selecionar "Remover arquivos adicionais no destino" nas opções de publicação de arquivo, em configurações na caixa de diálogo de publicação.

A dll está ausente no publicado (ambiente implementado). Essa é a razão pela qual ele está funcionando no local, ou seja, Visual Studio, mas não no Ambiente de Site do Azure.

Basta copiar Local = true nas propriedades da montagem (System.Web.Http.WebHost) e, em seguida, fazer uma reimplementação, pois deve funcionar bem.

Estou usando o vs2012 e acho que a atualização KB2781514 mudou algumas configurações. Todo o meu System.Web.Http no meu projeto MVC4 mudou para false e eu continuo recebendo esta mensagem. Eu havia alterado a All file in this projectpropriedade in publish, mas não está funcionando. Finalmente, tenho que mudar Copy Local = trueum por um e resolvi esse problema.

Eu recebi o mesmo erro e mudei minha versão de 4 para 3 e ela foi resolvida:

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

Eu tive o mesmo problema no meu aplicativo.

System.web.http.webhost not found.

Você só precisa copiar o system.web.http.webhostarquivo do seu projeto principal que você executa no Visual Studio e colá-lo no seu projeto publicadobin diretório do .

Depois disso, ele pode mostrar o mesmo erro, mas o nome do diretório foi alterado, pode ser system.web.http . Siga o mesmo procedimento acima. Funcionará após o upload de todos os arquivos. Isso devido ao pacote de pepitas no Visual Studio, que eles baixam da Internet, mas no servidor não é possível fazer o download.

Você pode encontrar este arquivo no bindiretório do projeto .

Isso aconteceu comigo no VS2013 (Atualização 5) / ASP.NET 4.5, no tipo de projeto "Aplicativo da Web" que inclui MVC e API da Web 2. O erro ocorreu logo após a criação do projeto e antes da adição de qualquer código. A adição da seguinte configuração corrige-a para mim. Após resolver o "System.Web.Helpers", ocorreram mais dois erros semelhantes surgidos para "System.Web.Mvc" e "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>

Faltavam várias DLLs. Mesmo se eu os copiasse manualmente no diretório da próxima vez que publiquei, eles desapareceriam. Cada um já estava definido como Copiar localmente no VS. A solução para mim foi definir cada um como Copiar localmente falso, salvar, criar e definir cada um para copiar localmente verdadeiro. Desta vez, quando publiquei todas as DLLs publicadas corretamente. Estranho

Se você tiver vários projetos em sua solução e um dos seus projetos falhar na criação devido a esse erro, verifique se instalou o pacote de nuget do WebApi Core nesse projeto. Simplesmente adicionar uma referência ao System.Web.Http não ajuda, você precisa instalar o pacote nuget correto nesse projeto.

Eu tinha vários projetos em minha solução e o WebApi Core já estava instalado em outro projeto. Mencionei o assembly System.Web.Http clicando com o botão direito do mouse e marcando o assembly na lista e ele não funcionou no Azure, embora localmente ele fosse compilado. Eu tive que remover a referência manual e adicionar o pacote de nuget do WebApi Core a cada projeto que precisava da referência de montagem.

No caso, se "Copy Local" já for True, às vezes acho que funcionará se você remover os arquivos para os quais foi publicado e publicar novamente.

Por exemplo, se você estiver usando o IIS, remova os sites e o conteúdo do diretório para o qual eles são publicados e publique novamente.

Pode haver versões mais antigas dos arquivos no destino; portanto, para garantir que você não esteja usando versões mais antigas, exclua tudo antes de publicar novamente.

Eu removi a seguinte entrada do web.config e funcionou para mim.

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

Verifique se a versão do pacote é igual na solução. Acabei de atualizar e atualizar o Microsoft.AspNet.Mvcpacote na solução e o problema foi resolvido.