ASP.NET Core 1.0 unter IIS-Fehler 502.5

Ich habe gerade meinen Server (Windows 2012R2) auf das .Net Core 1.0 RTMWindows Hosting Pack vom vorherigen aktualisiert .Net Core 1.0 RC2. Meine App funktioniert auf meinem PC ohne Probleme, aber der Server zeigt weiterhin Folgendes an:

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

Es funktionierte zuvor mit der RC2-Version. Ich weiß nicht, was schief gehen könnte.

Dies ist alles, was die Ereignisanzeige sagt:

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

Das Schlimmste ist, dass die App-Protokolle leer sind! Ich meine, diese stdout_xxxxxxxxx.log-Dateien sind vollständig leer und haben alle eine Größe von 0 Byte.

Was soll ich machen?? Wie kann ich die Fehlerursache ermitteln, wenn sie nicht protokolliert ist?

Ich konnte es durch Laufen beheben

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

an der Eingabeaufforderung, die mir einen viel aussagekräftigeren Fehler gab:

"Das angegebene Framework 'Microsoft.NETCore.App', Version '1.0.1' wurde nicht gefunden. - Überprüfen Sie die Anwendungsabhängigkeiten und zielen Sie auf eine Framework-Version ab, die installiert ist unter: C: \ Programme \ dotnet \ shared \ Microsoft.NETCore.App - Die folgenden Versionen werden installiert: 1.0.0 - Alternativ können Sie die Framework-Version '1.0.1' installieren.

Wie Sie sehen, war auf meinem Server die falsche NET Core-Version installiert. Ich konnte meine Anwendung ausführen, nachdem ich die vorherige Version 1.0.0 deinstalliert und die richtige Version 1.0.1 installiert hatte.

Ich hatte das gleiche Problem. In meinem Fall war die Berechtigung zur Benutzeridentität meines Anwendungspools nicht ausreichend. Auf der Seite " Veröffentlichen auf IIS " von asp.net doc sind einige Gründe für diesen Fehler aufgeführt:

• Wenn Sie eine eigenständige Anwendung veröffentlicht haben, bestätigen Sie, dass Sie keine Plattform buildOptionsfür project.jsondiesen Konflikt mit der Veröffentlichungs-RID eingerichtet haben. Geben Sie beispielsweise keine x86-Plattform an und veröffentlichen Sie mit einer RID von win81-x64 ( dotnet publish -c Release -r win81-x64). Das Projekt wird ohne Warnung oder Fehler veröffentlicht, schlägt jedoch mit den oben protokollierten Ausnahmen auf dem Server fehl.
• Überprüfen Sie das processPathAttribut für das <aspNetCore>Element in web.config, um sicherzustellen, dass es sich dotnetum eine tragbare Anwendung handelt, oder. \ My_application.exe für eine eigenständige Anwendung.
• Für eine tragbare Anwendung ist dotnet.exeder Zugriff über die PATH-Einstellungen möglicherweise nicht möglich. Vergewissern Sie sich, dass dies C:\Program Files\dotnet\in den Systempfadeinstellungen vorhanden ist.
• Für eine tragbare Anwendung ist dotnet.exedie Benutzeridentität des Anwendungspools möglicherweise nicht verfügbar. Stellen Sie sicher, dass die AppPool-Benutzeridentität Zugriff auf das C:\Program Files\dotnetVerzeichnis hat.
• Stellen Sie sicher, dass Sie die IIS-Integrations-Middleware korrekt referenziert haben, indem Sie die .UseIISIntegration()Methode der Anwendung aufrufen WebHostBuilder().
• Wenn Sie die .UseUrls()Erweiterungsmethode beim Selbsthosting mit Kestrel verwenden, stellen Sie sicher, dass sie vor der .UseIISIntegration()Erweiterungsmethode aktiviert ist WebHostBuilder(). .UseIISIntegration()muss den Urlfür den Reverse-Proxy festlegen, wenn Kestrel hinter IIS ausgeführt wird, und darf seinen Wert nicht überschreiben .UseUrls().

In meinem Fall war dies der vierte Grund. Ich habe ihn geändert, indem ich mit der rechten Maustaste auf meinen App-Pool geklickt habe. In der erweiterten Einstellung unter Prozessmodell habe ich die Identität auf einen Benutzer mit ausreichender Berechtigung festgelegt:

Ich habe dies mit einem Hard-Reset von IIS zum Laufen gebracht (ich hatte gerade erst das Hosting-Paket installiert).

Es stellt sich heraus, dass es nicht ausreicht, im IIS-Manager nur auf "Neu starten" zu klicken. Ich musste nur eine Eingabeaufforderung öffnen und 'iisreset' eingeben.

Also habe ich einen neuen Server bekommen, diesmal ist es Windows 2008R2 und meine App funktioniert gut.

Ich kann nicht sicher sagen, was das Problem mit dem alten Server war, aber ich habe eine Idee.

Da ich die App zuvor ohne Plattform kompiliert habe, habe ich die dllVersion erhalten, die nur funktioniert, wenn auf dem Zielhost ein .Net Core Windows HostingPaket installiert ist. In meinem Fall wurde es installiert und das war in Ordnung .

Nachdem die App nicht funktioniert hatte, entschied ich mich, sie als Konsolen-App mit win7-x64Laufzeit zu kompilieren . Dieses Mal, als ich exemeine App auf dem Server ausführte, stürzte sie mit einem Fehler über eine fehlende DLL ab:

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

Diese DLL stammt von Universal C Runtime und ist in Visual C ++ Redistributable für Visual Studio 2015 enthalten .

Ich habe versucht, dieses Paket (sowohl x64 als auch x86) zu installieren, aber es ist jedes Mal unter Windows Server 2012 R2 fehlgeschlagen (ich weiß nicht warum).

Als ich jedoch versuchte, sie auf dem neuen Server Windows Server 2008 R2 zu installieren, wurden sie erfolgreich installiert. Das könnte der Grund dafür gewesen sein, kann aber immer noch nicht sicher sagen.

Ich hatte das gleiche Problem beim Veröffentlichen der Web-App. Wenn noch jemand dieses Problem hat, beheben Sie es durch Ändern von {AppName} .runtimeconfig.json

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

Ändern Sie die Version von "version": "1.1.2" in "version": "1.1.1" und alles funktionierte einwandfrei

Ich hatte das gleiche Problem.

Um die genaue Quelle herauszufinden, habe ich die Anmeldung in der Datei web.config aktiviert:

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

und erstellter Protokollunterordner im MyWebService-Stammordner.

Nach dem Neustart von IIS und dem Versuch, die API auszuführen, ist ein Fehler aufgetreten, und es fehlte die richtige Core Runtime. Nach dem Herunterladen eines installierenden DotNetCore.1.0.5_1.1.2-WindowsHosting ist der Fehler verschwunden.

Hatte das gleiche Problem und alle Lösungen funktionierten nicht. Fand dieses Juwel und dachte, ich würde es weitergeben, wenn es jemand anderem hilft. Bei der Installation auf Server 2012 R2 wird der fehlende DLL-Fehler angezeigt. Versuchen Sie, VS C ++ 2015 neu zu installieren, und es wird ein Fehler angezeigt. Fix ist Folgendes zu tun:

Anscheinend hat die Datei C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msuProbleme bei der Installation. Öffnen Sie die Admin-Eingabeaufforderung.

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

HINWEIS: Ersetzen Sie das "..." durch den richtigen Ordnernamen. Installieren Sie anschließend das VS C ++ 2015-Paket neu.

Ich hatte ein ähnliches Problem und um Sherlock Holmes zu zitieren: " Wenn Sie das Unmögliche beseitigt haben, muss alles, was noch so unwahrscheinlich ist, die Wahrheit sein? "

Ich habe überprüft, ob das .NET Framework, auf das ich abzielte, auf dem Server installiert war, und es stellte sich heraus, dass dies nicht der Fall war. Ich habe das 4.6.2 .NET Framework installiert und es hat funktioniert.

Ich habe dieses Problem auf meinem Produktionsserver, nachdem mein VS-Projekt automatisch auf .NET Core 1.1.2 aktualisiert wurde.

Ich habe einfach die 1.1.2 .net-Kernlaufzeit von hier auf meinem Produktionsserver installiert: https://www.microsoft.com/net/download/core#/runtime

Gelöst Ich bin heute bei der Bereitstellung auf AZURE auf dasselbe Problem gestoßen . Dann habe ich das gleiche für lokales IIS versucht, habe das gleiche Problem bekommen. Da ich neu bei .net CORE bin, hatte ich einige Stunden vor der eigentlichen Lösung Probleme.

In unserer Lösung habe ich nach der Veröffentlichung in IIS meine Datei web.confile beobachtet, insbesondere unter der Zeile <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

In unserem Bereitstellungsordner sieht die generierte web.config folgendermaßen aus:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll -argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Versuchen Sie nun BITTE, die obige Konfiguration in Visual Studio Solution auf zu ändern<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

In unserem neuen Bereitstellungsordner sieht die generierte web.config folgendermaßen aus:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Und das hat mein Problem gelöst, hoffe es hilft.

Ich hatte das gleiche Problem, als ich meinen Entwicklungscomputer auf Core 1.0.1 aktualisierte, vergaß jedoch, den Server zu aktualisieren.

Beim Versuch, meine .NET Core 2.0-API in AWS EB zu veröffentlichen, wurde der HTTP-Fehler 502.5 angezeigt. Der Fehler wurde durch Hinzufügen des folgenden Codes zum .csproj behoben:

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

Ich hatte das gleiche Problem. Ich habe die Identität des Anwendungspools in ein Netzwerkdienstkonto geändert. Dann habe ich den Pfad zu dotnet.exe in der web.config explizit festgelegt, damit die Anwendung ordnungsgemäß funktioniert, wie @danielyewright in seinem Github- Kommentar sagte . Es funktioniert, nachdem der Pfad festgelegt wurde.

Vielen Dank

In meinem Fall war dieser Fehler darauf zurückzuführen, dass ich vergessen habe, project.json zu aktualisieren mit:

"buildOptions": {
    "emitEntryPoint": true
  }

Ich hatte den gleichen Fehler in Frage, mit den gleichen Problemen wie von VSG24 in Vorgeschlagene Antwort beschrieben - böse Fehlermeldung bei der Eingabe von 'dotnet' in CMD:

Das Programm kann nicht gestartet werden, da api-ms-win-crt-runtime-l1-1-0.dll fehlt

Ich habe dieses Problem gelöst, indem ich die folgenden 2 Updates unter Windows Server 2012 R2 manuell installiert habe (und die Voraussetzungen und alle anderen verknüpften Updates - lesen Sie die Installationsanweisungen auf der Microsoft-Website sorgfältig durch):

1. KB2919355
2. KB2999226

Hoffe das hilft jemandem.

Ich hatte das gleiche Problem, als ich versuchte, die Debug-Version meiner Webanwendung zu veröffentlichen. Dieser Satz von Dateien enthielt nicht die Datei web.configmit dem richtigen Wert des Attributs processPath.

Ich habe diese Datei aus der Release-Version übernommen. Der Wert wurde dem Pfad zu meiner exe-Datei zugewiesen.

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

In meinem Fall war ein Problem mit der auf dem Server installierten Net Core-Version. Ich installiere einfach die gleiche Version wie auf meinem Entwicklungscomputer und alles ist in Ordnung :-)

Ich musste die neueste .net Core-Version installieren, die hier zu finden ist . Sie müssen die Site oder den Server nicht neu starten

Ich habe es gelöst, indem ich der Anwendung der Site "Bearbeitungsberechtigung" hinzugefügt, dem physischen Verzeichnis zugeordnet und dann den Windows-Benutzer ausgewählt habe, der Zugriff auf diesen Stammordner haben könnte. (privates Netzwerk).

In meinem Fall muss ich nach der Installation AspNetCore.2.0.6.RuntimePackageStore_x64.exeund den Server neu starten , damit er ohne 502 fehlerhafte Gateway- und Proxy-Fehler funktioniert.DotNetCore.2.0.6-WindowsHosting.exe

AKTUALISIEREN:

Es gibt eine Möglichkeit, es ohne Neustart zu verwenden: https://stackoverflow.com/a/50808634/3634867

Öffnen Sie Eingabeaufforderung mit Administratoranmeldeinformationen

Geben Sie den folgenden Befehl ein und drücken Sie die Eingabetaste

> IISRESET

ODER

Öffnen Sie Visual Studio 2017 mit Administrator - Anmeldeinformationen

Geben Sie den folgenden Befehl in die Package Manager-Konsole ein und drücken Sie die Eingabetaste

PM > IISRESET

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

Für mich war dies darauf zurückzuführen, dass verschiedene Versionen von .Net Core installiert waren. Ich habe meinen Entwickler und Produktionsserver abgeglichen und es hat funktioniert.

Ich hatte auch dieses Problem (Der Fehler trat sowohl bei VS 15 als auch bei VS 17 auf). Auf VS15 wurde jedoch ein CONNECTION_REFUSEDFehler zurückgegeben, und auf VS17 wurde ein Fehler zurückgegeben ASP.NET Core 1.0 on IIS error 502.5.

FIX

1. Navigieren Sie zu Ihrem Projektverzeichnis und suchen Sie den versteckten Ordner .vs(er befindet sich im Verzeichnis des Projektordners ). (Denken Sie daran, versteckte Dateien / Ordner anzuzeigen)

2. Schließen Sie VS

3. Löschen Sie den .vs-Ordner
4. Starten Sie VS als Administrator (.vs-Ordner wird von VS neu erstellt)

Folgendes habe ich mir gedacht: Dies geschah kürzlich unter Windows 10, nachdem ein Update installiert wurde. Nach dem, was ich gesammelt habe, wurde ein Windows Defender-Update installiert, bei dem davon ausgegangen wurde, dass sich meine "Project.dll" (ein asp.net-Kernprojekt) wie ein Virus verhält und daher gelöscht wurde.

Eines der ersten Dinge, die Sie vorschlagen sollten, bevor Sie mit der Installation / Deinstallation beginnen, ist zu überprüfen, ob Ihre "Project.dll" dort ist, wo sie sein sollte.

Kopieren Sie es zurück an den Speicherort, wenn es nicht mehr vorhanden ist.

Wenn Sie Probleme beim Zurückkopieren der Datei haben, fügen Sie Ihrem Projektordner in Windows Defender einen Ausschluss hinzu . ( Erfahren Sie hier, wie das geht .)

Dies funktionierte sofort für mich und ich wiederholte es auf mehreren Servern der Anwendung.

Für mich war der connectionString in Startup.cs null in:

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

und es war null, weil die Anwendung nicht in appsettings.json nach der Verbindungszeichenfolge gesucht hat.

Musste Program.cs ändern zu:

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

Ich habe keine Ahnung, warum dies bei mir funktioniert hat, aber ich verwende die Windows-Authentifizierung und hatte diesen Code in meinem BuildWebHostIn Program.cs:

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

Nach dem Entfernen des .UserHttpSysBits funktioniert es jetzt und ich kann mich weiterhin als Domänenbenutzer authentifizieren.

BuildWebHost sieht jetzt so aus

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

Ich habe den gleichen Fehler erhalten und festgestellt, dass das Problem darin bestand, dass während der Veröffentlichung in Azure meine Datei web.config so geändert wurde, dass die folgende Zeile folgendermaßen endete:

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

Das Problem für die Produktion ist der Inhalt der Argumente: "-argFile IISExeLauncherArgs.txt"

Es scheint, dass dieses Problem im nächsten .NET Core SDK (derzeit in der Vorschau) behoben wird. Derzeit besteht die Problemumgehung darin, diesen Block zur .csproj-Datei hinzuzufügen:

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

Dadurch wird die Datei web.config geändert und der problematische Teil für die Veröffentlichung entfernt.

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

Ich hoffe es hilft.

Arbeitete für mich nach dem Ändern der Veröffentlichungskonfiguration.

Ich hatte ein ähnliches Problem (Asp.Net Core 2.x), das durch den Versuch verursacht wurde, eine 32-Bit-asp.net-Core-App in IIS auf einem 64-Bit-Windows-Server auszuführen. Die Hauptursache war, dass die automatisch generierte web.config (wenn Ihr Projekt nicht explizit eine enthält, die asp.net-Kernprojekte standardmäßig nicht enthalten) nicht den vollständigen Pfad zur ausführbaren dotnet-Datei enthält. Wenn Sie das Hosting-Bundle auf einem 64-Bit-Computer installieren, werden die 64- und 32-Bit-Versionen von dotnet installiert. Der Pfad wird jedoch standardmäßig in 64-Bit aufgelöst und Ihre 32-Bit-asp.net-Kern-App kann nicht geladen werden. In Ihrem Browser wird möglicherweise ein 502.5-Fehler angezeigt. Wenn Sie das Serverereignisprotokoll anzeigen, wird möglicherweise der Fehlercode 0x80004005 angezeigt. Wenn Sie versuchen, dotnet.exe über eine Eingabeaufforderung auszuführen, um Ihre asp.net-Kernanwendungs-DLL auf diesen Server zu laden, wird möglicherweise ein Fehler wie "BadImageFormatException" oder "BadImageFormatException" angezeigt.

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

Ich habe das gleiche Problem und der Grund , in meinem Fall war , dass der EF Kern versuchte Verbindungszeichenfolge aus zu lesen appsettings.development.jsonDatei. Ich habe es geöffnet und festgestellt, dass die Verbindungszeichenfolge kommentiert wurde.

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

Ich habe sie dann wie unten aufgehoben und das Problem gelöst:

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