Błąd HTTP 500.30 - Błąd uruchamiania ANCM w procesie

Eksperymentowałem z nową funkcją, która jest dostarczana z .net core sdk 2.2, która podobno ma poprawić wydajność o około 400%.

Imponujące, więc wypróbowałem to w moim projekcie ABP ( ASP.NET Boilerplate )

Template asp.net core mvc 4.0.2.0

Dodałem do mojego web.mv.cprojpliku następujące informacje

  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.2.0" PrivateAssets="All" />
  </ItemGroup>

Niestety nie sądzę, aby ta wersja frameworka ABP była kompatybilna, ponieważ projekt po prostu nie działa i wyrzuca: (ostatecznie)

Błąd HTTP 500.30 - Błąd uruchamiania ANCM w procesie

Sprawdziłem logi po ustawieniu stdoutLogEnabled="true"w web.config i ponownej próbie - ale żadnych wpisów.

Czy ktoś odniósł sukces, uruchamiając bieżący ABP na rdzeniu asp.net w konfiguracji procesu?

Myślę, że może to być coś, co jest dostępne tylko w ABP vNext.

W ASP.NET Core 2,2 wydano nowy wzorzec serwera / hostingu z usługami IIS o nazwie IIS InProcess hosting . Aby włączyć hostowanie w procesie, dodawany jest element csproj AspNetCoreHostingModel w celu ustawienia hostinguModel na inprocess w pliku web.config. Ponadto plik web.config wskazuje na nowy moduł o nazwie AspNetCoreModuleV2, który jest wymagany do hostingu w procesie.

Jeśli wdrażana maszyna docelowa nie ma ANCMV2, nie można korzystać z hostingu IIS InProcess. Jeśli tak, właściwym zachowaniem jest zainstalowanie pakietu hostingu dotnet na komputerze docelowym lub obniżenie wersji do AspNetCoreModule.

Źródło: jkotalik (Github)

Spróbuj zmienić sekcję w csproj (edytuj za pomocą edytora tekstu)

  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
  </PropertyGroup>

do następujących ...

 <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
    <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>
 </PropertyGroup>

Źródło (Github)

Od ASP.NET Core 3.0+ i Visual Studio 19 w wersji 16.3+ znajdziecie sekcje w pliku .csproj projektu jak poniżej-

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

Tam nie ma właściwości AspNetCoreHostingModel. Wybór modelu Hostingu znajdziesz we właściwościach projektu. Kliknij prawym przyciskiem myszy nazwę projektu w eksploratorze rozwiązań. Kliknij właściwości.

Kliknij menu Debug.

Przewiń w dół, aby znaleźć opcję Model hostingu.

Wybierz Out of Process.

Zapisz projekt i uruchom IIS Express.

UPDATE do wdrożenia na serwerze:

Kiedy publikujesz swoją aplikację na serwerze, pojawia się plik konfiguracyjny WWW, jak poniżej:

zmień wartość „hostingModel” z „inprocess” na „outofprocess”, jak poniżej:

W moim przypadku niedawno zmieniłem parametry połączenia z bazą danych w moim pliku appstettings.json. Podejrzewam, że bez logowania lub wychwytywania błędów ten błąd spowodował błąd „Błąd HTTP 500.30 - Niepowodzenie uruchomienia procesu ANCM”.

Zdarzyło mi się zauważyć wymianę między x-freestyler a Tahirem Khalidem, w której Tahir zasugerował problem IOC w starcie. Ponieważ mój rozruch nie zmienił się ostatnio, ale mój plik appstettings.json zmienił się - ustaliłem, że przyczyną problemu były parametry połączenia w moim pliku appstettings.json. Poprawiłem niepoprawne parametry połączenia i problem został rozwiązany. Podziękowania dla całej społeczności.

Jeśli korzystasz z programu Visual Studio i masz uruchomione jakiekolwiek wystąpienia, zamknij je wszystkie.

Powinieneś znaleźć .vspodfolder, w którym znajduje się rozwiązanie programu Visual Studio ( .slnplik).
Usuń .vsfolder i spróbuj ponownie z modelem hostingu w trakcie.

ASP.NET Core 2,2 lub nowszy: w przypadku samodzielnego wdrożenia 64-bitowego (x64), które korzysta z modelu hostingu w procesie, wyłącz pulę aplikacji dla procesów 32-bitowych (x86).

Na pasku bocznym Akcje Menedżera usług IIS> Pule aplikacji wybierz opcję Ustaw domyślne ustawienia puli aplikacji lub Ustawienia zaawansowane. Znajdź opcję Włącz aplikacje 32-bitowe i ustaw wartość na Fałsz.

Źródło: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/?view=aspnetcore-3.0#create-the-iis-site

Ten sam błąd wystąpił na moim komputerze deweloperskim z systemem Windows 10. Błąd nie zniknął po zainstalowaniu pakietu hostingu rdzenia dotnet. Musiałem przejść do Podglądu zdarzeń, aby uzyskać szczegółowy błąd. Twój podstawowy problem (jeśli występuje) może być inny niż mój. Chodzi o to, że jeśli korzystasz z komputera z systemem Windows, Podgląd zdarzeń służy do dostarczania szczegółów. Mam nadzieję, że to komuś pomoże.

Spojrzałem na dzienniki systemu Windows w aplikacji. Wyświetlił komunikat o błędzie i ślad stosu. Dowiedziałem się, że brakuje mi folderu o nazwie node_modules. Stworzyłem ten folder i to go naprawiło.

Nie wprowadziłem żadnych zmian w pliku web.config ani w pliku projektu. Moja wersja .NETCoreApp to 3.1

W niektórych przypadkach była to tylko literówka, która uszkadza i uniemożliwia analizę pliku ustawień JSON

Usunięcie wiersza AspNetCoreHostingModel w pliku .cproj działało dla mnie. W innym moim projekcie nie było takiej linii, która działała dobrze.

<PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup>

Miałem podobny problem podczas próby przejścia z hostingu OutOfProcess na hosting InProcess w projekcie .Net Core, który niedawno zaktualizowałem z 2.0 do 3.0.

Bez żadnego prawdziwego pomocnego błędu i po spędzeniu dni na próbach rozwiązania tego problemu w końcu znalazłem poprawkę dla mojego przypadku, którą pomyślałem, że podzielę się na wypadek, gdyby była pomocna dla każdego, kto ma z tym problem.

U mnie było to spowodowane kilkoma pakietami Microsoft.AspNetCore .

Po usunięciu wszystkich wymienionych pakietów Microsoft.AspNetCore, które miały wersję mniejszą niż 3.0.0 (nie było dostępne uaktualnienie> = 3.0.0 dla nich) ten błąd już nie występował.

To były pakiety, które usunąłem;

<PackageReference Include="Microsoft.AspNetCore" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.8" />
<PackageReference Include="Microsoft.AspNetCore.Server.IISIntegration" Version="2.2.1" />
<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.2.0" />

Wszystkie inne pakiety Microsoft.AspNetCore z wersją wyższą lub równą 3.0.0 działały dobrze.

Pobierz instalator pakietu .NET Core Hosting Bundle, korzystając z następującego łącza:

Bieżący instalator pakietu hostingu .NET Core (bezpośrednie pobieranie)

1. Uruchom instalator na serwerze IIS.
2. Zrestartuj serwer lub wykonaj polecenie net stop było / y, a następnie net start w3svc w powłoce poleceń.

Naprawiono to ustawienie profilu publikowania:

Skonfiguruj profil publikowania -> Ustawienia -> Opcje rozszerzeń witryny ->

• [x] Zainstaluj rozszerzenie witryny ASP.NET Core.

Mój jest z powodu UseKestrel () w program.cs Powinien to być .ConfigureKestrel () w 2.2

Więcej informacji na https://docs.microsoft.com/en-us/aspnet/core/migration/21-to-22?view=aspnetcore-2.2&tabs=visual-studio&WT.mc_id=-blog-scottha#update-kestrel -konfiguracja

Znalazłem inny problem, który zaczyna się od tego samego komunikatu o błędzie, co w pytaniu. Udostępniam to tutaj, abyś przed zmianą pliku projektu mógł upewnić się, że Twoje usługi są poprawnie zarejestrowane.

Używam również .netcore 2.2 i otrzymywałem ten sam komunikat o błędzie, więc zmieniłem plik projektu z InProcess na OutOfProcess, jak w wybranej odpowiedzi. Następnie znalazłem prawdziwą przyczynę mojego problemu, gdy otrzymałem komunikat „Nie można utworzyć instancji typu implementacji”: Przyczyną tego problemu było:

services.AddScoped<IMyService, IMyService>();

zamiast

services.AddScoped<IMyService, MyService>();

Powiązany wpis: Dlaczego pojawia się błąd „Nie można utworzyć wystąpienia typu implementacji” dla mojej usługi ogólnej?

Po spędzeniu całego dnia na walce ze sobą, decydując się na hostowanie mojej podstawowej aplikacji asp.net w usługach IIS z hostingiem InProcess, jestem w końcu dumny i odczuwam ulgę, że udało mi się rozwiązać ten problem. Godziny wielokrotnego przeglądania tych samych forów, blogów i pytań SO, które starały się jak najlepiej rozwiązać problem, nadal utknąłem po zastosowaniu wszystkich wyżej wymienionych podejść. Teraz opiszę tutaj moje doświadczenia związane z jego rozwiązaniem.

Krok 1: Utwórz witrynę internetową w usługach IIS

Krok 2: Upewnij się, że pula aplikacji dla witryny ma wersję .Net CLR ustawioną na „No Managed Code” i właściwość „Enable 32-bit Applications” w AppPool -> Advanced Settings jest ustawiona na false

Krok 3: Upewnij się, że projekt odwołuje się do .Net core 2.2

Krok 4: Dodaj następujący wiersz do pliku startup.cs w metodzie ConfigureServices

services.Configure<IISServerOptions>(options =>
{
     options.AutomaticAuthentication = false;
});

Krok 6: Dodaj następujące pakiety Nuget

Microsoft.AspNetCore.App w wersji 2.2.5 lub nowszej

Microsoft.AspNetCore.Server.IIS w wersji 2.2.2 lub nowszej

Krok 7: Dodaj następujący wiersz do pliku .csproj

<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>

Krok 8: Zbuduj i opublikuj swój kod (najlepiej bitowy x64 )

Krok 9: Upewnij się, że nazwa hosta Twojej witryny została dodana w pliku etc / hosts

Krok 10: Uruchom ponownie usługę publikowania w sieci World Wide Web

Teraz przetestuj podstawową aplikację asp.net i powinna być hostowana przy użyciu hostingu InProcess Aby zweryfikować, czy Twoja aplikacja jest hostowana w trybie InProcess, sprawdź nagłówki odpowiedzi i powinny zawierać następujący wiersz

Serwer: Microsoft-IIS / 10.0 (wersja IIS może zależeć od twojego systemu)

Aktualizacja : Pobierz i zainstaluj pakiet hostingu ASP.Net Core, który jest wymagany do jego działania

Rozwiązałem mój problem, uruchamiając dedykowaną pulę aplikacji dla AspNetCoreModuleV2

Opis:

HTTP Error 500.34 - ANCM Mixed Hosting Models Not Supported

Uruchomiłem wiele aplikacji w tej samej puli aplikacji. Niektóre aplikacje działały

<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />

Aplikacja powodująca błąd działała z AspNetCoreModuleV2

<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />

Utworzyłem nową pulę aplikacji przeznaczoną dla AspNetCoreModuleV2 i rozwiązałem mój problem.

Napotkałem ten problem w usłudze Azure App Service podczas uaktualniania z wersji 2,2 do 3,1. Przyczyną okazało się to, że rozszerzenie „Środowisko uruchomieniowe ASP.NET Core 2.2 (x86)” zostało zainstalowane w usłudze App Service. Usunięcie tego rozszerzenia z Kudu rozwiązało problem!

Wow, jest wiele odpowiedzi na to pytanie, ale miałem ten sam problem i moje rozwiązanie różniło się od wszystkiego, co przeczytałem tutaj, a także dość proste.

Miałem problemy z wdrażaniem mojej aplikacji do Azure z odpowiednimi ustawieniami środowiska, więc majstrowałem z plikiem launchsettings.json i zmieniłem wartość zmiennej ASPNETCORE_ENVIRONMENT w profilu IIS z „Development” na „Production” . Zmiana z powrotem na „Rozwój” rozwiązała problem.

  "profiles": {
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }

W moim przypadku była to zła wartość w pliku appsettings.json. Wartość była .\SQLEXPRESSi działała po zmianie na.\\SQLEXPRESS

U mnie błędnie wstrzyknięto DBContext w HostedService. Przepisałem to zgodnie z tym:

Jak należy wstrzyknąć wystąpienie DbContext do IHostedService?

i wszystko działało dobrze!

Ponieważ aplikacja ulega awarii. Dla kogo oszczędność czasu na tym wyjątku!

Kod błędu mówi, że zgłasza wyjątek, ponieważ nie może znaleźć pliku w początkowej fazie. Zobacz sekcję Ustawienia środowiska. W moim scenariuszu zadziałało, gdy zmieniłem następujący kod

var environment = whb.GetSetting("environment");

do

var environment = "Development";// whb.GetSetting("environment");

Ponieważ mam appsettings.development.json, ale nie mam appsettings.production.json. Dlaczego nie może znaleźć żadnego pliku, ponieważ szuka innej rzeczy we właściwym miejscu.

Dzięki .Net Core 2.2 powinieneś móc korzystać z modelu hostingu InProcess, ponieważ jest on naturalnie szybszy: wszystko jest przetwarzane w usługach IIS, bez dodatkowego przeskoku HTTP między usługami IIS a serwerem Kestrel aplikacji. Jedną rzeczą, którą możesz chcieć zrobić, jest dodanie tego tagu: AspNetCoreModuleV2 Zwróć uwagę na nową opcję AspNetCoreModuleV2 w porównaniu ze starszą opcją AspNetCoreModule. Inną ważną rzeczą do zrobienia jest zbadanie dziennika zdarzeń aplikacji systemu Windows w celu zidentyfikowania sprawcy. Chociaż komunikaty o błędach mogą być niejasne, czasami wskazują dokładne numery wierszy w kodzie, które spowodowały awarię. Ponadto, jeśli używasz CI / CD z TFS, mogą istnieć zmienne środowiskowe w pliku appsettings.json, które nie zostały poprawnie zastąpione ich wyznaczonymi wartościami i było to dla mnie jedno ze źródeł wyjątków.

Wystąpił problem w moim Program.cspliku. Próbowałem się połączyćAddAzureKeyVault tym, który został usunięty dawno temu.

Wniosek :

This error could come to due to any silly error in the application. Debug step by step your application startup process.

W moim przypadku miałem migrację, która kończyła się niepowodzeniem, gdy była uruchamiana w określonym środowisku na platformie Azure, ale działała poprawnie w środowisku deweloperskim. Ponieważ mamy usługę skonfigurowaną do uruchamiania migracji w ramach uruchamiania, faktyczne uruchomienie aplikacji internetowej kończy się niepowodzeniem.

Przeprowadziłem migrację ręcznie w środowisku, aby wykryć problem, a następnie dostosowałem go, aby poradzić sobie z różnicami danych w tym środowisku.

Jeśli ktoś wie, jak mogłem zobaczyć błąd migracji bez ręcznego uruchamiania bezpośrednio w bazie danych, byłoby to przydatne.

Po prostu miałem ten sam problem. Okazało się, że to był głupi błąd z mojej strony.

W ServiceCollection próbowałem zarejestrować plik abstract class

services.AddScoped<IMyInterface, MyClasss>();

gdzie MyClassbył abstractz jakiegoś nieznanego mi powodu hehe :)

Więc jeśli masz, po HTTP Error 500.30 - ANCM In-Process Start Failure prostu przejrzyjServiceCollection

Dla mnie wszystko było w porządku, ale problem był spowodowany publikowaniem przez różne wersje VS, dziwne !!! (najnowszy VS 2019 (16.4.2)). Kiedy publikuję aplikację z VS 2017, działa dobrze.

Rzeczywisty problem jest w pliku zależność json (np MyWebApp.deps.json) w folderze publikowania. Mam nadzieję, że to komuś pomoże.

Plz zobacz moją poprzednią odpowiedź w tym samym wątku, aby zrozumieć całość. Przepraszamy za wiele odpowiedzi

Po dalszym badaniu problem występował, ponieważ VS 2019 wybiera najnowszą łatkę (domyślne zachowanie VS) .net core 2.2, która jest 2.2.8, aby opublikować aplikację. Możemy ograniczyć to do konkretnej wybranej wersji za pomocą

<RuntimeFrameworkVersion>2.2.4</RuntimeFrameworkVersion>

Zobacz tutaj . To ostatecznie rozwiązało mój problem, mimo że najnowsza łatka nie została zastosowana. Mogę budować z dowolnego VS 2017 lub VS 2019, oba publikują aplikację dla wersji runtime .net core 2.2.0

Miałem ten sam błąd i problem dotyczył wersji pakietu Microsoft.Extension.Primitives nie była zgodna z wersją rdzenia .net. A to było odniesienie z jednego z odniesień do projektu z mojego projektu.

Kiedyś zmieniłem Microsoft.Extension.Primitives w tym projekcie. Ten problem został rozwiązany.

W dziennikach zdarzeń platformy Azure sprawdź, jaki błąd otrzymujesz i czy jest on powiązany z odwołaniem do pakietu. Spróbuj powyższej rzeczy, o której wspomniałem.

Ponieważ pakiety nuget są ściśle powiązane z wersją .net. Wystarczy upewnić się, że wszystkie pakiety odwołujące się do projektu powinny być ściśle powiązane z wersją .net.

Cóż, dla mnie miałem skomplikowany start aplikacji, w którym stworzyłem własny WebHostBuilder. To działało dobrze, ale nie powiodło się, gdy wypróbowałem tryb hostingu InProcess. Zakładam, że było coś, co przegapiłem, dzwoniąc do WebHostBuilder. Dlatego upewniłem się, że zawsze wywołuję WebHost.CreateDefaultBuilder (args), a następnie wprowadzam dodatkowe zmiany - zasadniczo tak, jak robią to nowe szablony aplikacji.

Lub dla szablonów ASP Core 3.1, które używają IHostBuilder (nie IWebHostBuilder), wywołaj ConfigureWebHostDefaults

 public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                // add stuff here
                webBuilder.UseStartup<Startup>();
            });

W moim przypadku żadne z powyższych rozwiązań nie zadziałało. Ale kiedy usunąłem plik myproject.vspscc z eksploratora rozwiązań, problem został rozwiązany.