ASP.NET Core 1.0 su IIS errore 502.5

Ho appena aggiornato il mio server (Windows 2012R2) al .Net Core 1.0 RTMpacchetto di hosting Windows dal precedente .Net Core 1.0 RC2. La mia app funziona sul mio PC senza problemi ma il server continua a mostrare:

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

In precedenza funzionava con la versione RC2. Non so cosa potrebbe andare storto.

Questo è tutto ciò che il visualizzatore di eventi dice:

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

la parte peggiore è che i log delle app sono vuoti! Voglio dire che quei file stdout_xxxxxxxxx.log sono completamente vuoti e hanno tutti una dimensione di 0 byte.

Cosa dovrei fare?? Come posso sapere la causa dell'errore quando non è registrato?

Sono stato in grado di risolverlo eseguendo

"C: \ Programmi \ dotnet \ dotnet.exe" "C: \ fullpath \ PROJECT.dll"

sul prompt dei comandi, che mi ha dato un errore molto più significativo:

"Il framework specificato 'Microsoft.NETCore.App', versione '1.0.1' non è stato trovato. - Controlla le dipendenze dell'applicazione e scegli come target una versione del framework installata in: C: \ Program Files \ dotnet \ shared \ Microsoft.NETCore.App - Sono installate le seguenti versioni: 1.0.0 - In alternativa, installa la versione del framework "1.0.1".

Come puoi vedere, avevo la versione NET Core sbagliata installata sul mio server. Sono stato in grado di eseguire la mia applicazione dopo aver disinstallato la versione precedente 1.0.0 e installato la versione corretta 1.0.1.

Ho avuto lo stesso problema, nel mio caso era un'autorizzazione insufficiente dell'identità utente del mio pool di applicazioni, sulla pubblicazione nella pagina IIS del documento asp.net, ci sono un paio di motivi elencati per questo errore:

• Se hai pubblicato un'applicazione indipendente, confermano che avete fatto non si imposta una piattaforma in buildOptionssu project.jsonin conflitto con il RID editrice. Ad esempio, non specificare una piattaforma x86 e pubblicare con un RID win81-x64 ( dotnet publish -c Release -r win81-x64). Il progetto verrà pubblicato senza avvisi o errori ma fallirà con le eccezioni registrate sopra sul server.
• Controllare l' processPathattributo <aspNetCore>sull'elemento in web.config per confermare che si tratta dotnetdi un'applicazione portatile o. \ My_application.exe per un'applicazione autonoma.
• Per un'applicazione portatile, dotnet.exepotrebbe non essere accessibile tramite le impostazioni PATH. Verificare che C:\Program Files\dotnet\esista nelle impostazioni PATH di sistema.
• Per un'applicazione portatile, dotnet.exepotrebbe non essere accessibile per l'identità utente del pool di applicazioni. Verificare che l'identità utente di AppPool abbia accesso alla C:\Program Files\dotnetdirectory.
• Confermare di aver fatto correttamente riferimento al middleware di integrazione IIS chiamando il .UseIISIntegration()metodo dell'applicazione WebHostBuilder().
• Se stai utilizzando il .UseUrls()metodo di estensione durante l'hosting autonomo con Kestrel, verifica che sia posizionato prima del .UseIISIntegration()metodo di estensione su WebHostBuilder(). .UseIISIntegration()deve impostare il Urlproxy inverso quando si esegue Kestrel dietro IIS e il suo valore non deve essere sovrascritto da .UseUrls().

Nel mio caso era il quarto motivo, l'ho modificato facendo clic con il pulsante destro del mouse sul mio pool di app e, nelle impostazioni avanzate in Process Model, ho impostato l'identità su un utente con autorizzazioni sufficienti:

Ho funzionato con un hard reset di IIS (avevo appena installato il pacchetto di hosting).

Si scopre che la semplice pressione di "Riavvia" in Gestione IIS non è sufficiente. Ho solo dovuto aprire un prompt dei comandi e digitare "iisreset"

Quindi ho un nuovo server, questa volta è Windows 2008R2 e la mia app funziona bene.

Non posso dire con certezza quale fosse il problema con il vecchio server ma ho un'idea.

Quindi, poiché in precedenza avevo compilato l'app senza alcuna piattaforma in mente, mi ha dato la dllversione che funziona solo se l'host di destinazione ha il .Net Core Windows Hostingpacchetto installato. Nel mio caso è stato installato e andava bene .

Dopo che l'app non ha funzionato, ho deciso di compilarla come app console con win7-x64runtime. Questa volta nel momento in cui ho eseguito la exemia app sul server, si è verificato un arresto anomalo con un errore relativo a una DLL mancante:

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

Quella dll proviene da Universal C Runtime incluso in Visual C ++ Redistributable per Visual Studio 2015 .

Ho provato a installare quel pacchetto (sia x64 che x86) ma non è riuscito ogni volta (non so perché) su Windows Server 2012 R2.

Ma quando ho provato a installarli nel nuovo server, Windows Server 2008 R2, si sono installati correttamente. Questa potrebbe essere stata la ragione alla base, ma ancora non posso dirlo con certezza.

Ho riscontrato lo stesso problema durante la pubblicazione dell'app Web. Se qualcuno ha ancora risolto il problema modificando {AppName} .runtimeconfig.json

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

Cambia la versione da "version": "1.1.2" a "version": "1.1.1" e tutto ha funzionato bene

Ho avuto lo stesso problema.

Per scoprirne l'origine esatta ho acceso il login nel file web.config:

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

e ha creato la sottocartella dei log nella cartella principale di MyWebService.

Dopo aver riavviato IIS e provato a eseguire l'API, ho ricevuto un errore e mancava il corretto Core Runtime. Dopo aver scaricato l'installazione di DotNetCore.1.0.5_1.1.2-WindowsHosting l'errore è sparito.

Aveva lo stesso problema e tutte le soluzioni non funzionavano. Ho trovato questo gioiello e ho pensato di passarlo se aiuta qualcun altro. Installa su Server 2012 R2 ottenendo l'errore mancante della DLL, prova a reinstallare VS C ++ 2015 e ottieni un errore. La soluzione consiste nel fare quanto segue:

Sembra che il file C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msuabbia problemi durante l'installazione. Apri il prompt dei comandi dell'amministratore fai:

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: sostituire "..." con il nome della cartella corretto. Dopo questo, reinstallare il pacchetto VS C ++ 2015.

Ho avuto un problema simile, e per citare Sherlock Holmes: " quando hai eliminato l'impossibile, tutto ciò che rimane, per quanto improbabile, deve essere la verità? "

Ho controllato se il framework .NET che stavo prendendo di mira era installato sul server e si è scoperto che non lo era. Ho installato il 4.6.2 .NET Framework e ha funzionato.

Ho riscontrato questo problema sul mio server di produzione dopo che il mio progetto VS è stato aggiornato automaticamente a .NET Core 1.1.2.

Ho semplicemente installato il runtime core 1.1.2 .net da qui sul mio server di produzione: https://www.microsoft.com/net/download/core#/runtime

RISOLTO Ho appena affrontato lo stesso problema oggi durante la distribuzione in AZURE . Poi ho provato lo stesso per IIS locale, ho ottenuto lo stesso problema. Dato che sono nuovo su .net CORE, ho lottato poche ore prima di risolverlo effettivamente.

Nella nostra soluzione, dopo aver pubblicato su IIS, ho osservato il mio file web.confile, specialmente sotto la riga <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

Nella nostra cartella di distribuzione il web.config generato ha il seguente aspetto:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll -argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Ora PER FAVORE, prova a modificare la configurazione sopra nella soluzione di Visual Studio in<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

Nella nostra nuova cartella di distribuzione il file web.config generato ha il seguente aspetto:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

E questo ha RISOLTO il mio problema, spero che aiuti.

Ho avuto lo stesso problema quando ho aggiornato la mia macchina di sviluppo a Core 1.0.1, ma ho dimenticato di aggiornare il server.

Ho ricevuto l'errore HTTP 502.5 durante il tentativo di pubblicare la mia API .NET Core 2.0 su AWS EB e l'ho risolto aggiungendo il seguente codice a .csproj:

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

Ho avuto lo stesso problema. Ho cambiato l'identità del pool di applicazioni nell'account del servizio di rete. Quindi ho impostato esplicitamente il percorso a dotnet.exe nel web.config affinché l'applicazione funzioni correttamente come ha detto @danielyewright nel suo commento su github . Funziona dopo aver impostato il percorso.

Grazie

Condividendo che nel mio caso questo errore era perché ho dimenticato di aggiornare project.json con:

"buildOptions": {
    "emitEntryPoint": true
  }

Ho avuto lo stesso errore in questione, con gli stessi problemi descritti da VSG24 in Risposta proposta - brutto messaggio di errore durante la digitazione di "dotnet" in CMD:

Il programma non può essere avviato perché manca api-ms-win-crt-runtime-l1-1-0.dll

Ho risolto questo problema installando manualmente i seguenti 2 aggiornamenti su Windows Server 2012 R2 (e i prerequisiti e tutti gli altri aggiornamenti collegati - leggi attentamente le istruzioni di installazione sul sito Web di Microsoft):

1. KB2919355
2. KB2999226

Spero che questo aiuti qualcuno.

Ho riscontrato lo stesso problema quando ho provato a pubblicare la versione di debug della mia applicazione web. Questo insieme di file non conteneva il file web.configcon il valore corretto di attributo processPath.

Ho preso questo file dalla versione di rilascio, il valore è stato assegnato al percorso del mio file exe.

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

Nel mio caso si è verificato un problema con la versione Net Core installata sul server. Ho appena installato la stessa versione della mia macchina di sviluppo e tutto è OK :-)

Dovevo installare l'ultima versione di .net Core trovata qui . Non è necessario riavviare il sito o il server

L'ho risolto aggiungendo "autorizzazione di modifica" all'applicazione del sito, mappato alla directory fisica e quindi selezionato l'utente di Windows che potrebbe avere accesso a questa cartella principale. (rete privata).

Nel mio caso, dopo aver installato AspNetCore.2.0.6.RuntimePackageStore_x64.exee DotNetCore.2.0.6-WindowsHosting.exe, devo riavviare il server per farlo funzionare senza 502 bad gateway ed errore proxy.

AGGIORNARE:

C'è un modo per utilizzarlo senza riavviare: https://stackoverflow.com/a/50808634/3634867

Apri il prompt dei comandi con l' amministratore credenziali di

Digita il seguente comando e premi invio

> IISRESET

O

Apri Visual Studio 2017 con amministratore credenziali di

Digita il seguente comando nella console di Gestione pacchetti e premi invio

PM > IISRESET

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

Per me è stato causato dall'installazione di diverse versioni di .Net Core. Ho abbinato il mio server di sviluppo e di produzione e ha funzionato.

Ho avuto anche questo problema (l'errore si è verificato sia su VS 15 che su 17). Tuttavia su VS15 ha restituito un CONNECTION_REFUSEDerrore e su VS17 è tornato ASP.NET Core 1.0 on IIS error 502.5.

FIX

1. Vai alla directory del tuo progetto e individua la cartella nascosta .vs(si trova nella cartella dei progetti dir). (Ricorda di mostrare file / cartelle nascosti)

2. Chiudi VS

3. Elimina .vs-folder
4. Avvia VS come amministratore (la cartella .vs verrà ricreata da VS)

Ecco cosa ho pensato, e questo è successo di recente su Windows 10 dopo l'installazione di un aggiornamento. Da quanto ho raccolto, è stato installato un aggiornamento di Windows Defender che presupponeva che il mio "Project.dll" (un progetto principale di asp.net) si comportasse come un virus, quindi è stato eliminato.

Quindi, una delle prime cose che ti suggerisco di fare prima di iniziare a installare / disinstallare roba è controllare confermare che il tuo "Project.dll" è dove dovrebbe essere.

Copialo di nuovo nella posizione se non è più lì.

Se hai difficoltà a copiare nuovamente il file, aggiungi un'esclusione alla cartella del progetto in Windows Defender . ( Scopri come farlo qui .)

Questo ha funzionato per me immediatamente e l'ho ripetuto su più server dell'applicazione.

Per me era che la connectionString in Startup.cs era nulla in:

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

ed era nullo perché l'applicazione non stava cercando in appsettings.json la stringa di connessione.

Ho dovuto cambiare Program.cs in:

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

Non ho idea del motivo per cui questo ha funzionato per me, ma sto usando l'autenticazione di Windows e avevo questo bit di codice sul mio BuildWebHostin Program.cs:

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

Dopo aver rimosso il .UserHttpSysbit, ora funziona e posso ancora autenticarmi come utente di dominio.

BuildWebHost ora sembra

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

Ho ricevuto lo stesso errore e ho scoperto che il problema era che durante la pubblicazione su Azure, il mio file web.config è stato modificato, quindi questa riga seguente è risultata così:

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

Il problema per la produzione sono i contenuti degli argomenti: "-argFile IISExeLauncherArgs.txt"

Sembra che questo problema verrà risolto nel prossimo .NET Core SDK (attualmente in anteprima), ma per ora, la soluzione alternativa è aggiungere questo blocco al file .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>

Questo modificherà il web.config e rimuoverà la parte problematica per la pubblicazione.

Riferimento: https://github.com/aspnet/websdk/issues/242

Spero che sia d'aiuto.

Ha funzionato per me dopo aver modificato la configurazione di pubblicazione.

Ho riscontrato un problema simile (Asp.Net Core 2.x) causato dal tentativo di eseguire un'app principale asp.net a 32 bit in IIS su un server Windows a 64 bit. La causa principale era che il file web.config generato automaticamente (se il progetto non ne include esplicitamente uno, che i progetti principali di asp.net non lo fanno per impostazione predefinita) non contiene il percorso completo dell'eseguibile dotnet. Quando installi il pacchetto di hosting su una macchina a 64 bit, installerà le versioni a 64 e 32 bit di dotnet, ma il percorso verrà risolto per impostazione predefinita a 64 bit e la tua app asp.net core a 32 bit non verrà caricata. Nel tuo browser potresti vedere un errore 502.5 e se guardi il registro degli eventi del server potresti vedere il codice di errore 0x80004005. Se si tenta di eseguire dotnet.exe da un prompt dei comandi per caricare la dll dell'applicazione principale asp.net su quel server, è possibile che venga visualizzato un errore del tipo "BadImageFormatException" o "

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

Ho avuto lo stesso problema e il motivo nel mio caso era che il core EF stava cercando di leggere la stringa di connessione dal appsettings.development.jsonfile. L'ho aperto e ho scoperto che la stringa di connessione era stata commentata.

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

Quindi li ho annullati come di seguito e il problema è stato risolto:

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