Erreur HTTP 502.5 - Échec du démarrage hors processus ANCM après la mise à niveau vers ASP.NET Core 2.2

Ma solution:

• supprimer tous les projets avec catalogue
• créer de nouveaux projets
• copiez tous les fichiers sauf program.cs et startup.cs
• copie manuelle des classes de démarrage et de programme vers le nouveau startup.cs et le nouveau programme.cs

Travaux.

J'ai rencontré ce problème et j'ai eu une solution différente. Pour moi, c'était que j'avais un package qui n'était plus à jour avec l'application (je l'avais mis à jour sur NuGet, et la bibliothèque n'avait pas été remplacée en production). La mise à jour du package l'a corrigé pour moi.

Notez avec ceci: j'ai dû exécuter manuellement dotnet.exe avec la dll du projet afin de voir le message qui l'a corrigé pour moi.

J'espère que cela aidera quelqu'un d'autre sur la route.

Dans mon cas, j'ai mis à niveau certains packages nuget vers net core 2.2, mais je n'avais pas installé le net core 2.2 sdk, alors je suis allé sur le site web net core pour télécharger le dernier sdk ou le dernier package d'exécution, puis j'ai fait un net stop was /y puis un net start w3svc dans le CMD en tant qu'administrateur. Problème résolu pour moi.

J'ai rencontré cette erreur après avoir essayé de publier à partir de VS2017 sur le serveur de production Windows 2016. (Cela a bien fonctionné dans IIS Express sur mon PC Win10 local.)

J'ai mis à jour les packages, toutes les versions correspondant et mises à jour dans mon code, les versions de base .net correspondant, redémarrer IIS, redémarrer ... pas de joie.

Dans le Publier> Configurer> Paramètres (onglet de gauche), j'ai dû définir le runtime cible de "Portable" à "win-x64" (ou tout ce qui est pertinent pour votre environnement). J'ai également opté pour "Supprimer les fichiers supplémentaires à destination".

«Portable» est le paramètre par défaut. Je ne suis pas sûr de ce qu'il faut pour que le runtime "Portable" fonctionne correctement, mais cela pourrait faire gagner du temps à quelqu'un d'autre si un runtime "Portable" n'est pas quelque chose dont vous avez besoin.

De manière générale, j'obtiens cette erreur si quelque chose ne correspond pas à mon environnement. Par exemple, une fois, je mettais à niveau l'un de mes projets vers .Net Core 3.1 à partir de la version 2.2 et je n'avais pas installé le bundle d'hébergement ASP.NET Core Runtime sur mon serveur:

https://dotnet.microsoft.com/download/dotnet-core/3.1

En outre, vous pouvez obtenir cette erreur si votre pool d'applications est défini sur True pour Activer les applications 32 bits. Essayer:

Gestionnaire IIS> Pools d'applications> nom du pool d'applications> (clic droit) Paramètres avancés> Activer les applications 32 bits = False

Cette erreur a commencé à apparaître sur notre serveur Dev. J'avais utilisé cette commande de publication qui crée un dossier «autonome» de fichiers pour le déploiement.

dotnet publish --output:bin/framework_dependent

Mon correctif consistait à publier à la place un déploiement "dépendant du framework" à l'aide de la commande suivante:

dotnet publish -c release -r win7-x64 --output:bin/self_contained

Le serveur de développement avait quelques versions de .NET Core installées (2.2.3 et 2.2.5) dans ce dossier * C:\Program Files\dotnet\shared

Je ne sais toujours pas pourquoi la publication autonome ne fonctionne pas. Vous pourriez penser que la publication autonome serait la méthode la plus fiable, mais dans mon cas, ce n'était pas le cas.

Ce billet de blog .NET Core a été utile.

J'ai rencontré ce problème aujourd'hui avec mon hébergement - localement tout va bien, mais une fois que je publie, j'obtiens cette erreur.

J'ai parcouru les packages et j'ai découvert que certains éléments de base de .net avaient été mis à niveau vers l'aperçu 3.0.

Ensuite, j'ai changé l'option de construction dans VS2019 de "Framework-Dependent" à "Self-content". Il a fallu 5 fois plus de temps pour construire et publier, mais maintenant cela fonctionne.

Maintenant, je vérifie avec le support technique de l'hôte ce qui pourrait être un problème - officiellement, ils ne prennent en charge que la version 2.1 / 2.2, donc cela pourrait être ces packages de 3.0 Preview, mais la version cible est 2.2.

Dans mon cas, c'était le niveau de journal mal défini dans le appsettings.json . Au lieu d' avertissement, j'ai eu Warn et cela a planté l'application avec l'erreur ci-dessus.

J'ai eu cette même erreur lors du déploiement de l'application principale .Net qui ciblait le framework .Net sur le serveur Windows. J'ai vérifié l'observateur d'événements sur le serveur et il s'avère que le serveur n'avait pas .net 4.7.2 installé.

L'installation a résolu le problème pour moi.

Mes problèmes étaient un fichier appsetttings.json mal formé. J'ai activé la journalisation standard via web.config et j'ai pu obtenir l'exception sous-jacente lançant cette erreur.

Encore un autre scénario qui a causé ce problème pour moi:

dotnet dev-certs https identité du pool d'applications avec un compte de service et j'ai dû exécuter dotnet dev-certs https sous cet utilisateur pour me débarrasser de «System.InvalidOperationException: Impossible de configurer le point de terminaison HTTPS». au démarrage.

Si la réinitialisation du projet et la copie manuelle des classes de programme et de démarrage fonctionnaient pour vous, alors quelque chose était clairement gâché. Il y a des problèmes sous-jacents plus importants avec cela. L'utilisation du modèle d'hébergement OutOfProcess est acceptable, mais avec .Net Core 2.2, vous devriez pouvoir utiliser le modèle d'hébergement InProcess, car il est naturellement plus rapide: tout est traité dans IIS, sans saut HTTP supplémentaire entre IIS et le serveur Kestrel de votre application .

Si vous cliquez avec le bouton droit sur votre fichier de projet dans l'explorateur de solutions Visual Studio, assurez-vous que la balise AspNetCoreModuleName a la valeur AspNetCoreModuleV2 (par opposition à l'ancienne AspNetCoreModule). Examinez également le journal des événements des applications Windows pour identifier le coupable potentiel. Même si les messages d'erreur sont quelque peu cryptiques, ils peuvent vous indiquer le numéro de ligne exact dans le code qui a causé l'échec.

Enfin, si vous utilisez CI / CD avec TFS, il se peut que des variables d'environnement dans le fichier appsettings.json n'aient pas été correctement remplacées par les valeurs réelles (URL, etc.).

Même échec lors de la publication du projet. Le problème était lié au dernier package Microsoft.AspNetCore.App . Faites-le simplement passer de 2.2.x à 2.2.0 ou allez à dotnet.microsoft.com/download/dotnet-core/2.2 et obtenez le dernier programme d' installation d' hébergement dotnet

On dirait que j'ai eu le même problème. Cela se produit parce que si vous n'avez pas de fichier global.json dans la solution, alors VS construisez (publiez) l'application principale .net avec la dernière version installée sur votre PC. Alors, je fais la solution suivante:

ajoutez un fichier global.json avec la version de base .net.

{
   "sdk": {
      "version": "2.2.402"
   }
}

Depuis docs.microsoft.com:

global.json peut être placé n'importe où dans la hiérarchie des fichiers. L'interface de ligne de commande recherche vers le haut à partir du répertoire du projet le premier global.json qu'il trouve. Vous contrôlez les projets auxquels s'applique un global.json donné en fonction de sa place dans le système de fichiers. L'interface de ligne de commande .NET recherche un fichier global.json en parcourant le chemin vers le haut à partir du répertoire de travail actuel. Le premier fichier global.json trouvé spécifie la version utilisée. Si cette version est installée, cette version est utilisée. Si le SDK spécifié dans le fichier global.json n'est pas trouvé, l'interface de ligne de commande .NET passe au dernier SDK installé. Le roll-forward est le même que le comportement par défaut, lorsqu'aucun fichier global.json n'est trouvé.

https://docs.microsoft.com/en-us/dotnet/core/versions/selection

Soyez attentif à la publication.

Lorsque je le publie sur mon environnement PreProd, cette configuration fonctionne bien: Portable

Mais sur mon environnement Prod, cette configuration ne fonctionne pas. J'ai dû choisir celui spécifique: win-x64

Je n'en connais pas la raison. Si quelqu'un sait, je serai reconnaissant de le savoir!

Le problème se produit lorsque j'essaie de déployer le site Web de base asp.net (modèle d'hébergement hors processus) sur le serveur Windows 2012r2 IIS dans l'environnement de production. J'ai corrigé cela avec cette solution:

Changez l'identité du pool d'applications en administrateur .

Cela m'est arrivé lorsque j'ai déployé du code à l'aide d' Entity Framework Core avec des migrations , et qu'il y avait une incompatibilité entre l'état de la base de données et les migrations dans le code.

Pour moi, le problème a été causé par dotnet publish créant une entrée web.config stdoutLogFile=".\logs\stdout" . La valeur correcte doit être stdoutLogFile="\\?\%home%\LogFiles\stdout" .

Référence MSDN: https://blogs.msdn.microsoft.com/waws/2018/06/10/troubleshooting-http-502-5-startup-issues-in-azure-appservice-for-asp-net-core-websites /

Cela peut être un bogue dans le runtime ASP.NET Core 2.2.0 qui peut avoir été corrigé dans une version ultérieure.

J'avais également le même problème. Et quand j'ai regardé la fenêtre de sortie de ma solution.

Ensuite, j'ai pu voir une erreur différente, qui est « Le processus cible s'est terminé sans déclencher l'événement démarré CoreCLR », pour résoudre ce problème, j'ai dû supprimer Microsoft.AspNetCore.All de mes packages Nuget et installer Microsoft.AspNetCore.App . J'ai également dû installer le bon SDK .Net à partir d' ici . Une fois que cela est fait, redémarré ma machine et ouvrez la solution, l'erreur a disparu. J'espère que cela aide

vous avez 2 solution (cette réponse fonctionne sur le serveur Windows, je ne sais rien sur le serveur Linux).

première:

• copier tous les dossiers (sauf les dossiers bin et obj) de votre projet sur le serveur

• ouvrez cmd dans le dossier de votre projet puis exécutez cette commande: dotnet run puis tous les avertissements et erreurs vous montrent (si vous avez une erreur sur la commande ci-dessus, ne reconnaissez pas le téléchargement de dot net core sdk à partir de ce lien )

seconde:

• vous devez changer l'attribut accommodationModel d'OutOfProcess en inprocess dans web.config et vous pouvez changer stdoutLogEnabled en valeur true pour obtenir l'erreur de votre projet dans le dossier logs
• lisez les erreurs de vos projets et corrigez-les.

dans mon cas, web.config est:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet" arguments=".\BMS.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
    </system.webServer>
  </location>
</configuration>

et je le change en:

<?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="dotnet" arguments=".\BMS.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="OutOfProcess" />
    </system.webServer>
  </location>
</configuration>

Cela m'est arrivé la première fois que j'ai publié une application Web Azure. Voici comment je l'ai résolu:

Parcourez le site en utilisant Kudo / FTP. Dans le dossier racine, il y a un dossier LogFiles où vous trouvez eventlog.xml . Dans ce fichier, je pouvais voir que mon application Web avait une exception SqlException lorsque Entity Framework Core essayait de configurer la base de données, ce qui m'a amené à vérifier les autorisations de la base de données (ce qui était le problème pour moi).

Si vous travaillez avec ASP.Net Core version 2.2, dans appsettings.json, commentez simplement la ligne -

"AllowedHosts": "*"

cela résout le problème. Mon application fonctionne bien.

Cette erreur peut se produire pour de nombreuses raisons. Dans mon cas, c'était une exception en raison du format invalide de appsettings.json. Ce que j'ai découvert, c'est en activant le journal stdout dans web.config.

Voici ce qui a fonctionné pour moi: - J'ai exécuté le fichier de démarrage du projet dans le dossier déployé (IIS). Notez que: cela ne résoudra pas le problème mais vous informera de la nature du problème. Dans mon cas, la cause du problème était une migration de base de données qui a échoué

Il semble que tout le monde a une réponse différente à cela. J'ai également eu ce problème. Comme vous pouvez le constater, de nombreuses choses différentes sont à l'origine de ce problème. Si vous ne trouvez aucune de ces solutions utile ou si vous rencontrez des problèmes pour essayer de passer par toutes ces différentes solutions, vous pouvez essayer d'exécuter votre application à partir de la ligne de commande à partir du dossier de publication.

Après la publication, si vous recevez cette erreur, accédez à votre dossier de publication, puis ouvrez une fenêtre de commande / terminal, après ce type dotnet .\YourStartupProject.dll , vous devriez recevoir une erreur d'exception, ce qui devrait faciliter la résolution du problème.

Par exemple, il s'agit d'une erreur que j'ai reçue en essayant un nouvel environnement sans configurer de serveur SQL et, bien sûr, recevrais cette erreur.

Application startup exception: System.Exception: Could not resolve a service of type 
'YourStartupProject.DataServices.DbContext.DbContext' for the parameter 
'context' of method 'Configure' on type 'YourStartupProject.Startup'. ---> 
System.ArgumentNullException: Value cannot be null.
Parameter name: connectionString

Une fois que vous avez résolu votre erreur, réessayez, rincez, répétez.

Pour moi, le problème était un appsettings.json manquant

Je sélectionne le fichier appsettings.json approprié (appsettings.production.json ou appsettings.development.json) en fonction d'une variable d'environnement. Il s'avère que appsettings.json est requis même si vous ne l'utilisez pas.

Mon problème était avec le fichier web.config après la publication. L'extension de fichier manquait dans processPath dans la balise aspNetCore. Dans mon cas, c'était .exe

Dans mon cas, EF Migrations a levé une exception sur le blocage de l'exécution de l'un d'entre eux en raison d'une perte de données potentielle. J'ai dû consulter les journaux d'applications personnalisés (le plus souvent le dossier Log) pour le savoir.

Je suppose que l'erreur mentionnée dans la question est due à des problèmes lors de la phase de démarrage de l'application. Et en effet, les migrations sont exécutées lors du démarrage d'une application, donc si elles échouent, l'application ne peut pas terminer le démarrage.

Donc, en général, lorsque nous obtenons une telle erreur, nous devons nous concentrer sur les choses qui ont un impact sur la logique de démarrage de l'application.

Pour moi, c'était le fichier web.config, assurez-vous de l'avoir et de spécifier correctement les chemins

<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\bin\Debug\netcoreapp2.0\logs\stdout">

L'observateur d'événements peut également être utile pour détecter les erreurs de démarrage de l'application.

Suivez ces étapes:

• créer un répertoire à la racine de votre projet: logs / stdout

• ouvrez le fichier web.config depuis la racine de votre projet et trouvez cette ligne:

  <aspNetCore processPath=".\web.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
  

• définissez stdoutLogEnabled sur true et enregistrez-le

• rechargez votre application et consultez les journaux dans le répertoire: logs / stdout

Ce problème survient également lorsqu'une valeur requise telle que le point de terminaison de l'API requis au démarrage du projet est manquante dans le paramètre d'application json. Vous pouvez le paramétrer et ne pas fournir de valeur pour le paramètre. Je reçois ceci dans Azure devops

J'ai défini stdoutLogEnabled sur true dans Web.config. Donc, dans le journal, j'ai découvert que l'erreur était BadImageFormatException . En fait, mon application Web était compilée en 32 bits, j'ai donc dû spécifier la version 32 bits de dotnet dans Web.config:

<aspNetCore processPath="C:\Program Files (x86)\dotnet\dotnet" arguments=".\MyApp.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="OutOfProcess" />

Une autre réponse qui pourrait aider d'autres personnes dans le même cas: nous avons un AppService sur Azure où il y a 3 projets NETCore déployés sur 3 chemins différents:

• One for Web (/ webapi)
• One for Mobile (/ mobileapi)
• Un pour Functions sans serveur, dans notre cas, c'était AzureFunctions (/ functionapi)

Depuis la mise à niveau vers NETCore3.x , nous avons compris que le modèle d'hébergement par défaut était "In-Process", nous avons donc dû modifier le fichier .csproj pour définir explicitement le modèle d'hébergement sur "Out-Of-Process" comme ceci:

    public static IWebHostBuilder CreateWebHostBuilder(string[] args)
    {
        return WebHost.CreateDefaultBuilder(args)
            .UseKestrel(options => options.AddServerHeader = false)
            .UseStartup<Startup>();
    }

Mais ce n'était pas suffisant: en fait, nous devons également éditer Program.cs. Pourquoi ? Parce que dans Program.cs celui généré par défaut dans NETCore3.x, vous avez le code suivant:

    public static IHostBuilder CreateHostBuilder(string[] args)
    {
        return Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
                webBuilder.ConfigureKestrel(o => o.AddServerHeader = false);
            });
    }

Lorsque nous avons remplacé cela par l'ancien code par la version NETCore2.x comme ci-dessous:

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

Après le déploiement, l'erreur 502.5 Échec de démarrage de l'ANCM a disparu :) J'espère que cette réponse pourra aider d'autres personnes.

BTW Je sais que cet article est lié à NETCore2.2, nous avons également rencontré le même problème mais nous avons décidé de passer à NETCore3.1 car NETCore2.2 n'était plus pris en charge et cette version était également boguée sur d'autres points.

Mon site .NET Core fonctionnait bien, mais après un certain temps, j'ai eu cette erreur ( Erreur HTTP 502.5 - Échec de démarrage ANCM Out-Of-Process ... ); J'ai essayé différentes méthodes. Enfin, j'ajoute un nouveau site Web dans IIS (avec un autre port), puis l'erreur a été résolue.

J'ai suivi l'étape ci-dessous et résolu. Bonne chance:)

Étape -1: Accédez à l'explorateur de solutions <Clic droit <Propriété

Étape 2:

Affichez votre infrastructure .Net Core ou modifiez-la selon vos besoins, mais assurez-vous que toutes les autres DLL existantes sont prises en charge ou que vous devez mettre à jour.

Étape 3: Téléchargez le package .NetCore sur votre PC
Voir le lien ci-dessous https://dotnet.microsoft.com/download

Même moi, j'ai été confronté au problème suivant: post dotnet core 2.1 à 3.1 et .netstandard 1.1 à 2.1 avec dotnet core 3.1 sdk.

Lorsque la commande dotnet publish -c Release été utilisée, les fichiers se bin\Release\netcoreapp3.1 auparavant dans le bin\Release\netcoreapp3.1 bin\Release\netcoreapp2.1\publish .

Pas sûr des paramètres exacts, nous avons toujours le dossier de publication, mais le déploiement à partir du répertoire parent du dossier de publication a fait l'affaire