ASP.NET Core 1.0 w przypadku błędu usług IIS 502,5

Właśnie zaktualizowałem mój serwer (Windows 2012R2) do .Net Core 1.0 RTMpakietu Windows Hosting z poprzedniego .Net Core 1.0 RC2. Moja aplikacja działa na moim komputerze bez żadnych problemów, ale serwer ciągle wyświetla:

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

Wcześniej działał z wersją RC2. Nie wiem, co może się nie udać.

To jest wszystko, co mówi przeglądarka zdarzeń:

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

najgorsze jest to, że dzienniki aplikacji są puste! Chodzi mi o to, że te pliki stdout_xxxxxxxxx.log są całkowicie puste i wszystkie mają rozmiar 0 bajtów.

Co powinienem zrobić?? Jak mogę poznać przyczynę błędu, jeśli nie jest on zarejestrowany?

Udało mi się to naprawić, uruchamiając

„C: \ Program Files \ dotnet \ dotnet.exe” „C: \ fullpath \ PROJECT.dll”

w wierszu polecenia, co dało mi znacznie bardziej znaczący błąd:

„Nie znaleziono określonej struktury„ Microsoft.NETCore.App ”w wersji„ 1.0.1 ”. - Sprawdź zależności aplikacji i wybierz wersję docelową platformy zainstalowanej w: C: \ Program Files \ dotnet \ shared \ Microsoft.NETCore.App - Instalowane są następujące wersje: 1.0.0 - Alternatywnie zainstaluj wersję frameworka „1.0.1”.

Jak widać, na moim serwerze zainstalowano niewłaściwą wersję NET Core. Mogłem uruchomić moją aplikację po odinstalowaniu poprzedniej wersji 1.0.0 i zainstalowaniu poprawnej wersji 1.0.1.

Miałem ten sam problem, w moim przypadku było to niewystarczające pozwolenie na tożsamość użytkownika mojej puli aplikacji, na stronie Publikowanie w usługach IIS w dokumencie asp.net, istnieje kilka powodów tego błędu:

• Jeśli opublikowała aplikację samodzielne, sprawdź, czy nie ustawić platformę w buildOptionsod project.jsonsprzeczny z publikowania RID. Na przykład nie określaj platformy x86 i publikuj z RID win81-x64 (dotnet publish -c Release -r win81-x64 ). Projekt opublikuje bez ostrzeżenia lub błędu, ale zakończy się niepowodzeniem z powyższymi zarejestrowanymi wyjątkami na serwerze.
• Sprawdź processPathatrybut <aspNetCore>elementu w web.config, aby potwierdzić, że takdotnet to aplikacja przenośna lub. \ My_application.exe - aplikacja samodzielna.
• W przypadku aplikacji przenośnej dotnet.exemoże nie być dostępna za pośrednictwem ustawień PATH. Potwierdź, żeC:\Program Files\dotnet\ istnieje w ustawieniach ŚCIEŻKI systemu.
• W przypadku aplikacji przenośnej dotnet.exemoże nie być dostępna dla tożsamości użytkownika puli aplikacji. Upewnij się, że tożsamość użytkownika AppPool ma dostęp do C:\Program Files\dotnetkatalogu.
• Upewnij się, że poprawnie odwołałeś się do oprogramowania pośredniczącego integracji usług IIS, wywołując .UseIISIntegration()metodę aplikacji WebHostBuilder().
• Jeśli używasz .UseUrls()metody rozszerzenia podczas samodzielnego hostowania z Kestrel, potwierdź, że jest ona umieszczona przed .UseIISIntegration()metodą rozszerzającą WebHostBuilder(). .UseIISIntegration()należy ustawić Urldla zwrotnego serwera proxy podczas uruchamiania Kestrel za usługami IIS i nie może mieć zastępowanej wartości przez .UseUrls().

W moim przypadku był to czwarty powód, zmieniłem go, klikając prawym przyciskiem myszy moją pulę aplikacji, aw ustawieniach zaawansowanych w obszarze Model procesu ustawiłem tożsamość na użytkownika z wystarczającymi uprawnieniami:

Mam to działając z twardym resetem IIS (właśnie zainstalowałem pakiet hostingowy).

Okazuje się, że samo naciśnięcie przycisku „Uruchom ponownie” w Menedżerze usług IIS nie wystarczy. Musiałem tylko otworzyć wiersz polecenia i wpisać „iisreset”

Dostałem więc nowy serwer, tym razem jest to Windows 2008R2 i moja aplikacja działa dobrze.

Nie mogę powiedzieć na pewno, jaki był problem ze starym serwerem, ale mam jeden pomysł.

Ponieważ wcześniej skompilowałem aplikację bez żadnej platformy, dała mi dllwersję, która działa tylko wtedy, gdy docelowy host ma .Net Core Windows Hostingzainstalowany pakiet. W moim przypadku został zainstalowany i to było w porządku .

Po tym, jak aplikacja nie działała, zdecydowałem się skompilować ją jako aplikację konsolową ze win7-x64środowiskiem wykonawczym. Tym razem w momencie, gdy uruchomiłem exemoją aplikację na serwerze, zawiesiła się z błędem dotyczącym brakującej biblioteki DLL:

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

Ta biblioteka dll pochodzi z uniwersalnego środowiska wykonawczego języka C, które jest zawarte w pakiecie redystrybucyjnym Visual C ++ dla programu Visual Studio 2015 .

Próbowałem zainstalować ten pakiet (zarówno x64, jak i x86), ale za każdym razem kończyło się to niepowodzeniem (nie wiem dlaczego) w systemie Windows Server 2012 R2.

Ale kiedy próbowałem zainstalować je na nowym serwerze, Windows Server 2008 R2, pomyślnie się zainstalowały. To mógł być powód tego, ale nadal nie mogę powiedzieć na pewno.

Miałem ten sam problem podczas publikowania aplikacji internetowej. Jeśli ktoś nadal ma ten problem, rozwiązał go, zmieniając {AppName} .runtimeconfig.json

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

Zmień wersję z „wersja”: „1.1.2” na „wersja”: „1.1.1” i wszystko działało dobrze

Miałem ten sam problem.

Aby znaleźć dokładne jego źródło włączyłem logowanie do pliku web.config:

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

i utworzył podfolder logów w folderze głównym MyWebService.

Po ponownym uruchomieniu IIS i próbie uruchomienia API wystąpił błąd i brakowało odpowiedniego Core Runtime. Po pobraniu instalacji DotNetCore.1.0.5_1.1.2-WindowsHosting błąd zniknął.

Miał ten sam problem i wszystkie rozwiązania nie działały. Znalazłem ten klejnot i pomyślałem, że przejdę dalej, jeśli pomoże to komuś innemu. Zainstaluj na serwerze 2012 R2, otrzymując błąd braku biblioteki DLL, spróbuj ponownie zainstalować VS C ++ 2015 i otrzymaj błąd. Poprawka polega na wykonaniu następujących czynności:

Wygląda na to, że plik C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msuma problemy z instalacją. Otwórz wiersz polecenia administratora, wykonaj:

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

UWAGA: zastąp „...” poprawną nazwą folderu. Następnie zainstaluj ponownie pakiet VS C ++ 2015.

Miałem podobny problem i cytując Sherlocka Holmesa: „ kiedy wyeliminowałeś niemożliwe, cokolwiek pozostaje, jakkolwiek nieprawdopodobne, musi być prawdą? ”

Sprawdziłem, czy docelowa platforma .NET jest zainstalowana na serwerze i okazuje się, że tak nie jest. Zainstalowałem 4.6.2 .NET Framework i zadziałało.

Ten problem wystąpił na moim serwerze produkcyjnym po automatycznej aktualizacji mojego projektu VS do .NET Core 1.1.2.

Po prostu zainstalowałem środowisko uruchomieniowe 1.1.2 .net core na moim serwerze produkcyjnym: https://www.microsoft.com/net/download/core#/runtime

ROZWIĄZANE Właśnie dzisiaj napotkałem ten sam problem podczas wdrażania do platformy AZURE . Następnie wypróbowałem to samo dla lokalnych usług IIS, napotkałem ten sam problem. Ponieważ jestem nowy w .net CORE, zmagałem się kilka godzin, zanim faktycznie go rozwiązałem.

W naszym rozwiązaniu, po opublikowaniu w IIS, zauważyłem mój plik web.confile, szczególnie poniżej linii <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

W naszym folderze wdrożeniowym wygenerowany plik web.config wygląda następująco:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll -argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Teraz PROSZĘ spróbuj zmienić powyższą konfigurację w rozwiązaniu Visual Studio na<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

W naszym nowym folderze wdrożeniowym wygenerowany plik web.config wygląda następująco:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

I to rozwiązało mój problem, mam nadzieję, że to pomoże.

Miałem ten sam problem, kiedy zaktualizowałem moją maszynę deweloperską do Core 1.0.1, ale zapomniałem zaktualizować serwer.

Otrzymałem błąd HTTP 502.5 podczas próby opublikowania mojego interfejsu API .NET Core 2.0 w AWS EB i rozwiązałem go, dodając następujący kod do pliku .csproj:

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

Miałem ten sam problem. Zmieniłem tożsamość puli aplikacji na konto usługi sieciowej. Następnie wyraźnie ustawiłem ścieżkę do dotnet.exe w pliku web.config, aby aplikacja działała poprawnie, jak powiedział @danielyewright na swoim githubie komentarza. Działa po ustawieniu ścieżki.

Dzięki

Udostępnianie, że w moim przypadku ten błąd był spowodowany tym, że zapomniałem zaktualizować plik project.json za pomocą:

"buildOptions": {
    "emitEntryPoint": true
  }

Miałem ten sam błąd, z tymi samymi problemami, które opisał VSG24 w Propozycji odpowiedzi - nieprzyjemny komunikat o błędzie podczas wpisywania `` dotnet '' w CMD:

Nie można uruchomić programu, ponieważ brakuje pliku api-ms-win-crt-runtime-l1-1-0.dll

Rozwiązałem to, ręcznie instalując następujące 2 aktualizacje w systemie Windows Server 2012 R2 (wraz z wymaganiami wstępnymi i wszystkimi innymi aktualizacjami połączonymi - przeczytaj uważnie instrukcje instalacji w witrynie firmy Microsoft):

1. KB2919355
2. KB2999226

Mam nadzieję, że to komuś pomoże.

Napotkałem ten sam problem, gdy próbowałem opublikować wersję debugowania mojej aplikacji internetowej. Ten zestaw plików nie zawierał pliku web.configo prawidłowej wartości atrybutu processPath.

Wziąłem ten plik z wersji Release, wartość została przypisana do ścieżki do mojego pliku exe.

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

W moim przypadku był problem z wersją Net Core zainstalowaną na serwerze. Po prostu instaluję tę samą wersję, co na moim komputerze deweloperskim i wszystko jest w porządku :-)

Musiałem zainstalować najnowszą wersję .net Core znalezioną tutaj . Nie ma potrzeby ponownego uruchamiania witryny lub serwera

Rozwiązałem to, dodając „uprawnienia do edycji” do aplikacji serwisu, mapowałem do katalogu fizycznego, a następnie wybrałem użytkownika systemu Windows, który mógłby mieć dostęp do tego folderu głównego. (prywatna sieć).

W moim przypadku po zainstalowaniu AspNetCore.2.0.6.RuntimePackageStore_x64.exei DotNetCore.2.0.6-WindowsHosting.exemuszę zrestartować serwer, aby działał bez błędu 502 złej bramy i proxy.

AKTUALIZACJA:

Jest sposób, abyś mógł go użyć bez restartu: https://stackoverflow.com/a/50808634/3634867

Otwórz wiersz polecenia z poświadczeniami administratora

Wpisz następujące polecenie i naciśnij Enter

> IISRESET

LUB

Otwórz program Visual Studio 2017 z poświadczeniami administratora

Wpisz następujące polecenie w konsoli Menedżera pakietów i naciśnij Enter

PM > IISRESET

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

U mnie było to spowodowane zainstalowaniem różnych wersji .Net Core. Dopasowałem mój serwer deweloperski i produkcyjny i zadziałało.

Miałem również ten problem (błąd wystąpił zarówno na VS 15, jak i 17). Jednak na VS15 zwrócił CONNECTION_REFUSEDbłąd, a na VS17 zwrócił ASP.NET Core 1.0 on IIS error 502.5.

NAPRAWIĆ

1. Przejdź do katalogu swojego projektu i znajdź ukryty folder .vs(znajduje się w katalogu projektów). (Pamiętaj, aby pokazać ukryte pliki / foldery)

2. Zamknij VS

3. Usuń folder .vs
4. Uruchom VS jako administrator (folder .vs zostanie odtworzony przez VS)

Oto, do czego doszedłem, a stało się to niedawno w systemie Windows 10 po zainstalowaniu aktualizacji. Z tego, co zebrałem, zainstalowano aktualizację programu Windows Defender, która zakładała, że ​​mój plik „Project.dll” (podstawowy projekt asp.net) zachowywał się jak wirus, więc został usunięty.

Tak więc jedną z pierwszych rzeczy, które proponuję zrobić przed rozpoczęciem instalowania / odinstalowywania programów, jest sprawdzenie, czy plik „Project.dll” jest tam, gdzie powinien.

Skopiuj go z powrotem do lokalizacji, jeśli już jej nie ma.

Jeśli masz trudności z skopiowaniem pliku z powrotem, dodaj wykluczenie do folderu projektu w programie Windows Defender . ( Dowiedz się, jak to zrobić tutaj .)

To zadziałało dla mnie natychmiast i powtórzyłem to na wielu serwerach aplikacji.

Dla mnie było to, że connectionString w Startup.cs był pusty w:

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

i był pusty, ponieważ aplikacja nie szukała parametrów połączenia w pliku appsettings.json.

Musiałem zmienić Program.cs na:

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

Nie mam pojęcia, dlaczego to zadziałało, ale używam uwierzytelniania systemu Windows i miałem ten fragment kodu na moim BuildWebHostw Program.cs:

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

Po usunięciu tego .UserHttpSysbitu działa i nadal mogę uwierzytelniać się jako użytkownik domeny.

BuildWebHost teraz wygląda

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

Otrzymałem ten sam błąd i odkryłem, że problem polegał na tym, że podczas publikowania na platformie Azure mój plik web.config został zmodyfikowany, więc następująca linia zakończyła się następująco:

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

Problemem dla produkcji jest zawartość argumentów: „-argFile IISExeLauncherArgs.txt”

Wygląda na to, że ten problem zostanie rozwiązany w następnym zestawie .NET Core SDK (obecnie w wersji zapoznawczej), ale na razie obejściem jest dodanie tego bloku do pliku .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>

Spowoduje to zmodyfikowanie pliku web.config i usunięcie problematycznej części do publikacji.

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

Mam nadzieję, że to pomoże.

U mnie zadziałało po zmianie konfiguracji publikowania.

Miałem podobny problem (Asp.Net Core 2.x), który był spowodowany próbą uruchomienia 32-bitowej aplikacji asp.net core w usługach IIS na 64-bitowym serwerze Windows. Główną przyczyną było to, że plik web.config, który jest generowany automatycznie (jeśli projekt nie zawiera jawnie jednego, którego projekty podstawowe asp.net nie zawierają domyślnie) nie zawiera pełnej ścieżki do pliku wykonywalnego dotnet. Po zainstalowaniu pakietu hostingowego na komputerze 64-bitowym zainstaluje on 64 i 32-bitowe wersje dotnet, ale ścieżka zostanie domyślnie rozwiązana na 64-bitową, a 32-bitowa aplikacja asp.net core nie zostanie załadowana. W przeglądarce możesz zobaczyć błąd 502.5, a jeśli spojrzysz na dziennik zdarzeń serwera, możesz zobaczyć kod błędu 0x80004005. Jeśli spróbujesz uruchomić dotnet.exe z wiersza polecenia w celu załadowania biblioteki DLL aplikacji asp.net core na tym serwerze, może zostać wyświetlony błąd, taki jak „BadImageFormatException” lub „

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

Mam ten sam problem, a powodem w moim przypadku było to, że rdzeń EF próbował odczytać parametry połączenia z appsettings.development.jsonpliku. Otworzyłem go i stwierdziłem, że parametry połączenia zostały skomentowane.

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

Następnie zwolniłem je jak poniżej i problem został rozwiązany:

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