ASP.NET Core 1.0 no erro 502.5 do IIS


112

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



3
Como isso está relacionado? O código de erro é claramente diferente. Sem falar no fato de que eu disse que funciona no meu próprio PC com IIS.
Vahid Amiri

1
Em primeiro lugar, eu disse possivelmente relacionado, uma vez que menciona isso Failed to start process with commandline 'dotnet ./bin/Debug/netcoreapp1.0/WebApplication2.dll', Error Code = '0x80004005'.- a mesma linha de comando e código de erro que você está relatando. Em segundo lugar, só porque roda na sua máquina, mas não na máquina remota, indica que algo está diferente no servidor. Se você pudesse expandir como o aplicativo é implantado no servidor, isso seria útil.
Brendan Green

o que você quer dizer com seu app funcionando no seu pc .. quer dizer que você tem um projeto implantando no iis? estou ryt?
Vijunav Vastivch

1
@ VSG24 Você viu esta seção do documento asp.net? Publicando no IIS , ele lista erros comuns e tem alguns motivos listados para o erro 502.5.
Hamid Mosalla

Respostas:


112

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.


2
Consegui usar isso para descobrir que precisava do NodeJS instalado ... pois dá uma "mensagem muito mais significativa".
Tim Harker

Eu não posso te dizer quanto tempo perdi com isso. Obrigado. Meu erro estava relacionado a um certificado ausente. Por que não consegui obter esse erro por meio de algum método lógico?
Sprague

4
Alguém pode me dizer qual é o comando? O que é C: \ fullpath \ dotnet ?? O caminho para seu aplicativo, mas o que é dotnet ? Não há nenhum arquivo dotnet na pasta do projeto
Jeremy Thompson

9
@JeremyThompson é o caminho do dotnet.exe, que normalmente está localizado em: C: \ Arquivos de programas \ dotnet \ dotnet.exe
hatsrumandcode

1
Acabei de encontrar esse erro depois que uma atualização do .NET CORE 2.1.3 o corrigiu instalando o .NET SDK / runtime correto.
Mike Bovenlander

68

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: identidade do usuário do meu pool de aplicativos


1
Esta é a resposta que eu procurava !, no meu caso era o pool de aplicativos também ....
Armando Ramirez

3
Obrigado. No meu caso, o problema era com o caminho para o dotnet. Encontrado tais registros no sistema Visualizador de eventos: Failed to start process with commandline '"dotnet" .\PROJECT.dll', ErrorCode = '0x80070002'.
0x49D1

Eu acrescentaria outro motivo: "O instalador não conseguiu obter o VC ++ Redistributable", pois meu servidor não tem conexão com a Internet, ele não pôde baixar este pacote ... Portanto, você deve baixá-lo manualmente: link e instalá-lo.
Paco Mendez

4
dotnetestava no meu caminho, mas exigia a reinicialização do servidor para que fosse reconhecido.
Danny Cullen

no meu caso, tenho que especificar o valor --runtime no comando de publicação se eu fornecer a opção --framework, caso contrário NÃO forneça --framework e ele está descobrindo o tempo de execução por padrão.
Gomes

65

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'


Eu também pressionei a reciclagem verde iis no nó raiz do servidor da web na IU. Isso resolveu para mim, combinado com a configuração do usuário para o pool de aplicativos paraLocalSystem
JP Hellemons

Obrigado Michael ... Isso resolveu meu problema também. Estava procurando uma resposta por algumas horas. Obrigado!
birwin

2
Tx! Sua resposta me lembrou disso nos documentos do ms "Reiniciar o sistema ou executar net stop foi / y seguido por net start w3svc em um prompt de comando para pegar uma mudança no PATH do sistema." (depois de instalar o pacote .NET Core Windows Server Hosting)
Quinton Smith

Resolveu meu problema também. Obrigado
Met-u

Funcionou para mim. Obrigado :)
Husnain Shabbir

11

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.


5

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


5

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.


3
IMO você deve remover os asteriscos do valor 'verdadeiro' para evitar qualquer confusão.
AperioOculus

4

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.


4

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.


4

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


Encontrei o mesmo problema, mas com o recém-lançado net core 2.0.6. Corrigido ao instalar o Net Core SDK 2.0.6 em um servidor de produção
dodbrian

4

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.


Ei @Agni, isso funcionou para mim, obrigado. Mas, toda vez que tento publicar o projeto novamente no Azure, ele é reconstruído e o web.config é automaticamente alterado de volta para o original, com a parte que causa o problema: "-argFile IISExeLauncherArgs.txt". Você encontrou uma solução para isso? (Estou usando o asp.net core 2.0).
Rodrigo Pires

1
no meu caso, tive que mudar processPath="dotnet"para processPath="C:\Program Files\dotnet\dotnet.exe". então funcionou.
vaheeds

3

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


Para mim, reinstalei o SDK do núcleo da rede a partir daqui: microsoft.com/net/core#windows e funcionou.
Jean

1
VS2017 agora é .NET Core 1.1 por padrão - todos os servidores remotos precisam ser atualizados antes de publicar projetos atualizados no IIS. Você pode obter a mensagem de erro mais útil (".NET core 1.1 não instalado"), mas executandodotnet .\YOURPROJDLL.dll
Coruscate5

3

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>

2

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


2

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

"buildOptions": {
    "emitEntryPoint": true
  }

2

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.


2

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" ... />

2

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



2

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


2

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


2

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

2

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.


1

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)

1

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.


1

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();

1

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();

Estou tendo autenticação de cookie no núcleo aspnet. Como faço para configurar?
kudlatiger

@kudlatiger Desculpe, não tenho certeza - sua melhor aposta é criar uma pergunta separada
Bassie

1

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.


Os atributos startupTimeLimit e requestTimeout adicionados parecem ser um bug de ferramenta .
Mark G

1

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

insira a descrição da imagem aqui


Desculpe, não posso ver imagens na minha organização. O download das imagens está bloqueado (na maioria das organizações).
Auguste

0

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>

0

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;"
  }
}
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.