ASP.NET Core 1.0 no erro 502.5 do IIS

Acabei de atualizar meu servidor (Windows 2012R2) para .Net Core 1.0 RTMo pacote de hospedagem do Windows do anterior .Net Core 1.0 RC2. Meu aplicativo funciona no meu PC sem problemas, mas o servidor continua mostrando:

HTTP Error 502.5 - Process Failure


Common causes of this issue:

The application process failed to start
The application process started but then stopped
The application process started but failed to listen on the configured port

Anteriormente, funcionava com a versão RC2. Não sei o que pode dar errado.

Isso é tudo que o visualizador de eventos diz:

Failed to start process with the commandline 'dotnet .\MyWebApp.dll'. Error code = '0x80004005'.

a pior parte é que os logs do aplicativo estão vazios!Quero dizer, aqueles arquivos stdout_xxxxxxxxx.log estão completamente vazios e todos têm tamanho de 0 byte.

O que devo fazer?? Como posso saber a causa do erro quando ele não está logado ??

Consegui consertar executando

"C: \ Arquivos de programas \ dotnet \ dotnet.exe" "C: \ fullpath \ PROJECT.dll"

no prompt de comando, o que me gerou um erro muito mais significativo:

"A estrutura especificada 'Microsoft.NETCore.App', versão '1.0.1' não foi encontrada. - Verifique as dependências do aplicativo e direcione uma versão da estrutura instalada em: C: \ Arquivos de programas \ dotnet \ shared \ Microsoft.NETCore.App - As seguintes versões estão instaladas: 1.0.0 - Como alternativa, instale a versão do framework '1.0.1'.

Como você pode ver, eu tinha a versão errada do NET Core instalada no meu servidor. Consegui executar meu aplicativo depois de desinstalar a versão anterior 1.0.0 e instalar a versão correta 1.0.1.

Eu tive o mesmo problema, no meu caso foi a permissão insuficiente da identidade do usuário do meu pool de aplicativos, na página Publicando na página IIS do documento asp.net, há alguns motivos listados para este erro:

• Se você publicou um aplicativo independente, confirme que não configurou uma plataforma buildOptionsdeproject.json que os conflitos com o RID publicação. Por exemplo, não especifique uma plataforma de x86 e publique com um RID de win81-x64 ( dotnet publish -c Release -r win81-x64). O projeto será publicado sem aviso ou erro, mas falhará com as exceções registradas acima no servidor.
• Verifique o processPathatributo no <aspNetCore>elemento em web.config para confirmar que édotnet para um aplicativo portátil ou. \ My_application.exe para um aplicativo independente.
• Para um aplicativo portátil, dotnet.exe pode não estar acessível por meio das configurações de PATH. Confirme se C:\Program Files\dotnet\existe nas configurações de PATH do sistema.
• Para um aplicativo portátil, dotnet.exepode não estar acessível para a identidade do usuário do Pool de Aplicativos. Confirme se a identidade do usuário AppPool tem acesso ao C:\Program Files\dotnetdiretório.
• Confirme se você referenciou corretamente o middleware de integração do IIS chamando o .UseIISIntegration()método do aplicativo WebHostBuilder().
• Se você estiver usando o .UseUrls()método de extensão ao fazer a auto-hospedagem com Kestrel, confirme se ele está posicionado antes do .UseIISIntegration()método de extensão ativado WebHostBuilder(). .UseIISIntegration()deve definir o Urlpara o proxy reverso ao executar o Kestrel atrás do IIS e não ter seu valor substituído por .UseUrls().

No meu caso, foi o quarto motivo, mudei clicando com o botão direito em meu pool de aplicativos e, na configuração avançada em Modelo de Processo, defini a Identidade para um usuário com permissão suficiente:

Eu consegui isso trabalhando com uma reinicialização forçada do IIS (eu tinha acabado de instalar o pacote de hospedagem).

Acontece que apenas pressionar 'Reiniciar' no Gerenciador do IIS não é suficiente. Eu só tive que abrir um prompt de comando e digitar 'iisreset'

Então, comprei um novo servidor, desta vez é o Windows 2008R2 e meu aplicativo funciona bem.

Não posso dizer ao certo qual era o problema com o servidor antigo, mas tenho uma ideia.

Então, porque eu anteriormente compilei o aplicativo sem nenhuma plataforma em mente, ele me deu a dllversão que só funciona se o host de destino tiver o .Net Core Windows Hostingpacote instalado. No meu caso foi instalado e tudo bem .

Depois que o aplicativo não funcionou, decidi compilá-lo como um aplicativo de console com win7-x64 tempo de execução. Desta vez, no momento em que executei o exedo meu aplicativo no servidor, ele travou com um erro sobre uma dll ausente:

The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing

Essa dll é do Universal C Runtime que está incluído no Visual C ++ Redistributable for Visual Studio 2015 .

Tentei instalar esse pacote (x64 e x86), mas falhou todas as vezes (não sei por quê) no Windows Server 2012 R2.

Mas quando tentei instalá-los no novo servidor, Windows Server 2008 R2, eles foram instalados com sucesso. Essa pode ter sido a razão por trás disso, mas ainda não posso dizer com certeza.

Tive o mesmo problema ao publicar o aplicativo da web. Se alguém ainda tiver esse problema corrigido alterando {AppName} .runtimeconfig.json

    {
  "runtimeOptions": {
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "1.1.2"
    },
    "configProperties": {
      "System.GC.Server": true
    }
  }
}

Mude a versão de "versão": "1.1.2" para "versão": "1.1.1" e tudo funcionou bem

Eu tive o mesmo problema.

Para descobrir a origem exata dele, liguei o arquivo web.config de login:

<aspNetCore processPath="dotnet" arguments=".\MyWebService.dll" stdoutLogEnabled="**true**" stdoutLogFile=".\logs\stdout" />

e criou a subpasta de logs na pasta raiz MyWebService.

Depois de reiniciar o IIS e tentar executar a API, recebi um erro e faltava o Core Runtime adequado. Depois de baixar um DotNetCore.1.0.5_1.1.2-WindowsHosting de instalação, o erro desapareceu.

Tive o mesmo problema e todas as soluções não funcionaram. Encontrei esta joia e pensei em passar adiante se ajudasse outra pessoa. Instale no Server 2012 R2 obtendo o erro DLL ausente, tente reinstalar o VS C ++ 2015 e obtenha um erro. Consertar é fazer o seguinte:

Parece que o arquivo C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msutem problemas para ser instalado. Abra o prompt de comando do administrador:

c:
mkdir tmp
mkdir tmp\tmp
move "C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msu" c:\tmp
expand -F:* c:\tmp\Windows8.1-KB2999226-x64.msu c:\tmp\tmp
dism /online /add-package /packagepath:c:\tmp\tmp\Windows8.1-KB2999226-x64.cab

NOTA: substitua "..." pelo nome da pasta correto. Depois disso, reinstale o pacote VS C ++ 2015.

Eu tive um problema semelhante, e para citar Sherlock Holmes: " quando você eliminou o impossível, o que restar, por mais improvável que seja, deve ser a verdade? "

Eu verifiquei se o .NET framework que eu estava almejando estava instalado no servidor e descobri que não estava. Instalei o 4.6.2 .NET Framework e funcionou.

Tive esse problema no meu servidor de produção depois que meu projeto VS foi atualizado automaticamente para o .NET Core 1.1.2.

Simplesmente instalei o tempo de execução do núcleo 1.1.2 .net daqui em meu servidor de produção: https://www.microsoft.com/net/download/core#/runtime

RESOLVIDO Acabei de passar pelo mesmo problema hoje durante a implantação no AZURE . Então tentei o mesmo para o IIS local, obtive o mesmo problema. Como sou novo no .net CORE, lutei algumas horas antes de realmente resolvê-lo.

Em nossa solução, depois de publicar no IIS, observei meu arquivo web.confile, especialmente abaixo da linha <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

Em nossa pasta de implantação, o web.config gerado se parece com:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll -argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Agora, por favor, tente alterar a configuração acima na solução do Visual Studio para<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

Em nossa nova pasta de implantação, o web.config gerado se parece com:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

E isso resolveu meu problema, espero que ajude.

Tive o mesmo problema quando atualizei minha máquina dev para o Core 1.0.1, mas esqueci de atualizar o servidor.

Eu estava recebendo o erro HTTP 502.5 ao tentar publicar minha API .NET Core 2.0 no AWS EB e resolvi isso adicionando o seguinte código ao .csproj:

  <PropertyGroup>
    <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
  </PropertyGroup>

Eu tive o mesmo problema. Mudei a identidade do pool de aplicativos para a conta de serviço de rede. Em seguida, defino explicitamente o caminho para dotnet.exe no web.config para que o aplicativo funcione corretamente, como @danielyewright disse em seu github comentário . Funciona depois de definir o caminho.

obrigado

Compartilhar que, no meu caso, esse erro foi porque esqueci de atualizar o project.json com:

"buildOptions": {
    "emitEntryPoint": true
  }

Eu tive o mesmo erro em questão, com os mesmos problemas descritos por VSG24 na resposta proposta - mensagem de erro desagradável ao digitar 'dotnet' no CMD:

O programa não pode ser iniciado porque api-ms-win-crt-runtime-l1-1-0.dll está faltando

Resolvi isso instalando manualmente as 2 atualizações a seguir no Windows Server 2012 R2 (e os pré-requisitos e todas as outras atualizações vinculadas - leia as instruções de instalação cuidadosamente no site da Microsoft):

1. KB2919355
2. KB2999226

Espero que isso ajude alguém.

Eu enfrentei o mesmo problema quando tentei publicar a versão de depuração do meu aplicativo da web. Este conjunto de arquivos não contém o arquivo web.configcom o valor adequado de atributoprocessPath .

Peguei este arquivo da versão de lançamento, o valor foi atribuído ao caminho para o meu arquivo exe.

<aspNetCore processPath=".\My.Web.App.exe" ... />

No meu caso foi problema com a versão Net Core instalada no servidor. Acabei de instalar a mesma versão da minha máquina de desenvolvimento e está tudo OK :-)

Eu precisava instalar a última versão .net Core encontrada aqui . Não há necessidade de reiniciar o site ou servidor

Resolvi isso adicionando "permissão de edição" ao aplicativo do site, mapeado para o diretório físico e, em seguida, selecionei o usuário do Windows que poderia ter acesso a esta pasta raiz. (rede privada).

No meu caso, depois de instalar AspNetCore.2.0.6.RuntimePackageStore_x64.exee DotNetCore.2.0.6-WindowsHosting.exe, preciso reiniciar o servidor para que funcione sem 502 erro de gateway e proxy ruins.

ATUALIZAR:

Existe uma maneira de usá-lo sem reiniciar: https://stackoverflow.com/a/50808634/3634867

Abra o prompt de comando com o administrador credenciais de

Digite o seguinte comando e pressione Enter

> IISRESET

OU

Abra o Visual Studio 2017 com administrador credenciais de

Digite o seguinte comando no Console do gerenciador de pacotes e pressione Enter

PM > IISRESET

PM> IISRESET
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted

Para mim, foi causado por ter diferentes versões do .Net Core instaladas. Eu combinei meu dev e o servidor de produção e funcionou.

Eu também tive esse problema (o erro ocorreu no VS 15 e no 17). No entanto, no VS15 ele retornou um CONNECTION_REFUSEDerro e no VS17 ele retornou ASP.NET Core 1.0 on IIS error 502.5.

CONSERTAR

1. Navegue até o diretório do projeto e localize a pasta oculta .vs(localizada no diretório da pasta de projetos). (Lembre-se de mostrar arquivos / pastas ocultos)

2. Fechar VS

3. Excluir pasta .vs
4. Inicie o VS como administrador (a pasta .vs será recriada pelo VS)

Aqui está o que eu percebi, e isso aconteceu recentemente no Windows 10 depois que uma atualização foi instalada. Pelo que percebi, foi instalada uma atualização do Windows Defender que presumia que meu "Project.dll" (um projeto principal do asp.net) se comportava como um vírus, por isso foi excluído.

Então, uma das primeiras coisas que sugiro que você faça antes de começar a instalar / desinstalar coisas é verificar seu "Project.dll" está onde deveria estar.

Copie-o de volta para o local se ele não estiver mais lá.

Se você estiver tendo dificuldade para copiar o arquivo de volta, adicione uma exclusão à pasta do projeto no Windows Defender . ( Aprenda como fazer isso aqui .)

Isso funcionou para mim instantaneamente e eu o repeti em vários servidores de aplicativos.

Para mim, o connectionString em Startup.cs era nulo em:

services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

e era nulo porque o aplicativo não estava procurando em appsettings.json pela string de conexão.

Tive que alterar Program.cs para:

public static void Main(string[] args)
{
    BuildWebHost(args).Run();
}

public static IWebHost BuildWebHost(string[] args) =>
     WebHost.CreateDefaultBuilder(args)
     .ConfigureAppConfiguration((context, builder) => builder.SetBasePath(context.HostingEnvironment.ContentRootPath)
     .AddJsonFile("appsettings.json").Build())
     .UseStartup<Startup>().Build();

Não tenho ideia de por que isso funcionou para mim, mas estou usando a Autenticação do Windows e tinha este pedaço de código no meu BuildWebHostem Program.cs:

.UseStartup<Startup>()
.UseHttpSys(options =>
{
    options.Authentication.Schemes =
        AuthenticationSchemes.NTLM | AuthenticationSchemes.Negotiate;
    options.Authentication.AllowAnonymous = false;
})
.Build();

Depois de remover o .UserHttpSysbit, ele agora funciona e ainda posso me autenticar como um usuário de domínio.

BuildWebHost agora parece

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
    .UseStartup<Startup>()
    .Build();

Eu estava recebendo o mesmo erro e descobri que o problema era que, durante a publicação no Azure, meu arquivo web.config foi modificado, então esta linha a seguir acabou assim:

<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" startupTimeLimit="3600" requestTimeout="23:00:00" />

O problema para Produção é o conteúdo dos argumentos: "-argFile IISExeLauncherArgs.txt"

Parece que esse problema será resolvido no próximo .NET Core SDK (atualmente em visualização), mas, por enquanto, a solução alternativa é adicionar este bloco ao arquivo .csproj:

<Target Name="bug_242_workaround" AfterTargets="_TransformWebConfig">
    <Exec Command="powershell &quot;(Get-Content '$(PublishDir)Web.config').replace(' -argFile IISExeLauncherArgs.txt', '') | Set-Content '$(PublishDir)Web.config'&quot;" />
  </Target>

Isso modificará o web.config e removerá a parte problemática da publicação.

Referência: https://github.com/aspnet/websdk/issues/242

Espero que ajude.

Funcionou para mim depois de alterar a configuração de publicação.

Eu tive um problema semelhante (Asp.Net Core 2.x) que foi causado ao tentar executar um aplicativo de núcleo asp.net de 32 bits no IIS em um servidor Windows de 64 bits. A causa raiz foi que o web.config que é gerado automaticamente (se o seu projeto não incluir um explicitamente, o que os projetos principais do asp.net não incluem por padrão) não contém o caminho completo para o executável dotnet. Quando você instala o pacote de hospedagem em uma máquina de 64 bits, ele instala as versões de 64 e 32 bits do dotnet, mas o caminho será resolvido por padrão para 64 bits e o aplicativo principal do asp.net de 32 bits não será carregado. Em seu navegador, você pode ver um erro 502.5 e, se olhar o log de eventos do servidor, poderá ver o código de erro 0x80004005. Se você tentar executar dotnet.exe em um prompt de comando para carregar a dll do aplicativo principal do asp.net nesse servidor, poderá ver um erro como "BadImageFormatException" ou "

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <location path="." inheritInChildApplications="false">
        <system.webServer>
            <handlers>
                <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
            </handlers>
            <aspNetCore processPath="C:\Program Files (x86)\dotnet\dotnet.exe" arguments=".\My32BitAspNetCoreApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
       </system.webServer>
   </location>
</configuration>

Eu tive o mesmo problema e o motivo no meu caso foi que o núcleo EF estava tentando ler a string de conexão do appsettings.development.jsonarquivo. Eu o abri e descobri que a string de conexão foi comentada.

//{
//  "ConnectionStrings": {
//    "DefaultConnection": "Server=vaio;Database=Goldentaurus;Trusted_Connection=True;",
//    "IdentityConnection": "Server=vaio;Database=GTIdentity;Trusted_Connection=True;"
//  }
//}

Então, descomprometi-os como abaixo e o problema foi resolvido:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=vaio;Database=Goldentaurus;Trusted_Connection=True;",
    "IdentityConnection": "Server=vaio;Database=GTIdentity;Trusted_Connection=True;"
  }
}