ASP.NET Core 1.0 sur l'erreur IIS 502.5

Je viens de mettre à jour mon serveur (Windows 2012R2) vers .Net Core 1.0 RTMle pack d'hébergement Windows du précédent .Net Core 1.0 RC2. Mon application fonctionne sur mon PC sans aucun problème, mais le serveur continue d'afficher:

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

Il fonctionnait auparavant avec la version RC2. Je ne sais pas ce qui pourrait mal tourner.

C'est tout ce que dit l'observateur d'événements:

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

le pire, c'est que les journaux des applications sont vides! Je veux dire que ces fichiers stdout_xxxxxxxxx.log sont complètement vides et ont tous une taille de 0 octet.

Que devrais-je faire?? Comment puis-je connaître la cause de l'erreur lorsqu'elle n'est pas enregistrée?

J'ai pu le réparer en courant

"C: \ Program Files \ dotnet \ dotnet.exe" "C: \ fullpath \ PROJECT.dll"

sur l'invite de commande, ce qui m'a donné une erreur beaucoup plus significative:

"Le framework spécifié 'Microsoft.NETCore.App', version '1.0.1' est introuvable. - Vérifiez les dépendances de l'application et ciblez une version de framework installée à: C: \ Program Files \ dotnet \ shared \ Microsoft.NETCore.App - Les versions suivantes sont installées: 1.0.0 - Vous pouvez également installer la version du framework '1.0.1'.

Comme vous pouvez le voir, j'avais la mauvaise version de NET Core installée sur mon serveur. J'ai pu exécuter mon application après avoir désinstallé la version précédente 1.0.0 et installé la bonne version 1.0.1.

J'ai eu le même problème, dans mon cas, il s'agissait d'une autorisation insuffisante de l'identité de l'utilisateur de mon pool d'applications, sur la page Publication sur IIS de asp.net doc, il y a plusieurs raisons répertoriées pour cette erreur:

• Si vous avez publié une application autonome, vérifiez que vous n'avez pas défini une plate - forme buildOptionsde project.jsonque les conflits avec la publication RID. Par exemple, ne spécifiez pas une plate-forme de x86 et publiez avec un RID de win81-x64 ( dotnet publish -c Release -r win81-x64). Le projet sera publié sans avertissement ni erreur mais échouera avec les exceptions enregistrées ci-dessus sur le serveur.
• Vérifiez l' processPathattribut de l' <aspNetCore>élément dans web.config pour confirmer qu'il s'agit dotnetd'une application portable ou. \ My_application.exe pour une application autonome.
• Pour une application portable, dotnet.exepeut ne pas être accessible via les paramètres PATH. Confirmez qu'il C:\Program Files\dotnet\existe dans les paramètres PATH système.
• Pour une application portable, dotnet.exepeut ne pas être accessible pour l'identité de l'utilisateur du pool d'applications. Confirmez que l'identité de l'utilisateur AppPool a accès à l' C:\Program Files\dotnetannuaire.
• Confirmez que vous avez correctement référencé le middleware d'intégration IIS en appelant la .UseIISIntegration()méthode de l'application WebHostBuilder().
• Si vous utilisez la .UseUrls()méthode d'extension lors de l'auto-hébergement avec Kestrel, confirmez qu'elle est positionnée avant la .UseIISIntegration()méthode d'extension activée WebHostBuilder(). .UseIISIntegration()doit définir le Urlpour le proxy inverse lors de l'exécution de Kestrel derrière IIS et ne pas avoir sa valeur remplacée par .UseUrls().

Dans mon cas, c'était la quatrième raison, je l'ai changé en cliquant avec le bouton droit de la souris sur mon pool d'applications, et dans les paramètres avancés sous Modèle de processus, j'ai défini l'identité sur un utilisateur avec suffisamment d'autorisations:

Je l'ai fait fonctionner avec une réinitialisation matérielle d'IIS (je venais juste d'installer le package d'hébergement).

Il s'avère que le simple fait d'appuyer sur «Redémarrer» dans IIS Manager ne suffit pas. Je devais juste ouvrir une invite de commande et taper 'iisreset'

J'ai donc un nouveau serveur, cette fois c'est Windows 2008R2 et mon application fonctionne bien.

Je ne peux pas dire avec certitude quel était le problème avec l'ancien serveur, mais j'ai une idée.

Donc, parce que j'ai déjà compilé l'application sans aucune plate-forme à l'esprit, cela m'a donné la dllversion qui ne fonctionne que si l'hôte cible a .Net Core Windows Hostinginstallé le package. Dans mon cas, il a été installé et c'était bien .

Après que l'application n'a pas fonctionné, j'ai décidé de la compiler en tant qu'application console avec win7-x64comme runtime. Cette fois, au moment où j'ai exécuté le exede mon application sur le serveur, il s'est écrasé avec une erreur concernant une dll manquante:

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

Cette dll provient d'Universal C Runtime qui est inclus dans le redistribuable Visual C ++ pour Visual Studio 2015 .

J'ai essayé d'installer ce package (à la fois x64 et x86) mais il a échoué à chaque fois (je ne sais pas pourquoi) sur Windows Server 2012 R2.

Mais lorsque j'ai essayé de les installer sur le nouveau serveur, Windows Server 2008 R2, ils ont été installés avec succès. Cela pourrait avoir été la raison derrière cela, mais je ne peux toujours pas le dire avec certitude.

J'ai eu le même problème lors de la publication de l'application Web. Si quelqu'un a toujours ce problème résolu en modifiant {AppName} .runtimeconfig.json

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

Changez la version de "version": "1.1.2" à "version": "1.1.1" et tout a bien fonctionné

J'ai eu le même problème.

Pour en connaître la source exacte, j'ai activé la journalisation dans le fichier web.config:

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

et créé le sous-dossier des journaux dans le dossier racine MyWebService.

Après avoir redémarré IIS et essayé d'exécuter l'API, j'ai eu une erreur et il manquait le Core Runtime approprié. Après avoir téléchargé une installation DotNetCore.1.0.5_1.1.2-WindowsHosting, l'erreur a disparu.

Avait le même problème et toutes les solutions ne fonctionnaient pas. J'ai trouvé ce bijou et j'ai pensé que je passerais si cela aidait quelqu'un d'autre. Installez sur le serveur 2012 R2 en obtenant l'erreur DLL manquante, essayez de réinstaller VS C ++ 2015 et obtenez une erreur. Le correctif consiste à faire ce qui suit:

Il semble que le fichier C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msua des problèmes en cours d'installation. Ouvrez l'invite de commande d'administration:

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

REMARQUE: remplacez le "..." par le nom de dossier correct. Après cela, réinstallez le package VS C ++ 2015.

J'ai eu un problème similaire, et pour citer Sherlock Holmes: " quand vous avez éliminé l'impossible, ce qui reste, aussi improbable soit-il, doit être la vérité? "

J'ai vérifié si le framework .NET que je ciblais était installé sur le serveur, et il s'avère que ce n'était pas le cas. J'ai installé le Framework 4.6.2 .NET et cela a fonctionné.

J'ai eu ce problème sur mon serveur de production après la mise à niveau automatique de mon projet VS vers .NET Core 1.1.2.

J'ai simplement installé le moteur d'exécution principal 1.1.2 .net à partir d'ici sur mon serveur de production: https://www.microsoft.com/net/download/core#/runtime

RÉSOLU Je viens de rencontrer le même problème aujourd'hui lors du déploiement sur AZURE . Ensuite, j'ai essayé la même chose pour IIS local, j'ai eu le même problème. Comme je suis nouveau sur .net CORE, j'ai eu du mal quelques heures avant de le résoudre.

Dans notre solution, après avoir publié sur IIS, j'ai observé mon fichier web.confile, spécialement sous la ligne <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

Dans notre dossier de déploiement, le web.config généré ressemble à ceci:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll -argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Maintenant, veuillez essayer de changer la configuration ci-dessus dans la solution Visual Studio pour<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

Dans notre nouveau dossier de déploiement, le web.config généré ressemble à ceci:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Et cela a résolu mon problème, j'espère que cela aidera.

J'ai eu le même problème lorsque j'ai mis à jour ma machine de développement vers Core 1.0.1, mais j'ai oublié de mettre à jour le serveur.

J'obtenais l'erreur HTTP 502.5 en essayant de publier mon API .NET Core 2.0 sur AWS EB, et je l'ai résolu en ajoutant le code suivant au .csproj:

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

J'ai eu le même problème. J'ai changé l'identité du pool d'applications en compte de service réseau. Ensuite, j'ai explicitement défini le chemin vers dotnet.exe dans le web.config pour que l'application fonctionne correctement comme @danielyewright l'a dit dans son commentaire github . Cela fonctionne après avoir défini le chemin.

Merci

Partager cela dans mon cas, cette erreur était due au fait que j'ai oublié de mettre à jour project.json avec:

"buildOptions": {
    "emitEntryPoint": true
  }

J'ai eu la même erreur en question, avec les mêmes problèmes que ceux décrits par VSG24 dans la réponse proposée - message d'erreur désagréable lors de la saisie de 'dotnet' dans CMD:

Le programme ne peut pas démarrer car api-ms-win-crt-runtime-l1-1-0.dll est manquant

J'ai résolu ce problème en installant manuellement les 2 mises à jour suivantes sur Windows Server 2012 R2 (et les pré-requis et toutes les autres mises à jour liées - lisez attentivement les instructions d'installation sur le site Web de Microsoft):

1. KB2919355
2. KB2999226

J'espère que cela aide quelqu'un.

J'ai rencontré le même problème lorsque j'ai essayé de publier la version Debug de mon application Web. Cet ensemble de fichiers ne contenait pas le fichier web.configavec la valeur d'attribut appropriée processPath.

J'ai pris ce fichier de la version Release, la valeur a été attribuée au chemin d'accès à mon fichier exe.

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

Dans mon cas, il y avait un problème avec la version Net Core installée sur le serveur. Je viens d'installer la même version que sur ma machine de développement et tout va bien :-)

J'avais besoin d'installer la dernière version de .net Core trouvée ici . Pas besoin de redémarrer le site ou le serveur

Je l'ai résolu en ajoutant une "autorisation d'édition" à l'application du site, mappé sur le répertoire physique et ensuite sélectionné l'utilisateur Windows qui pourrait avoir accès à ce dossier racine. (Réseau privé).

Dans mon cas, après l'installation de AspNetCore.2.0.6.RuntimePackageStore_x64.exeet DotNetCore.2.0.6-WindowsHosting.exe, je dois redémarrer le serveur pour qu'il fonctionne sans erreur 502 de passerelle et de proxy.

METTRE À JOUR:

Il existe un moyen de l'utiliser sans redémarrage: https://stackoverflow.com/a/50808634/3634867

Ouvrez l' invite de commande avec les informations d'identification de l' administrateur

Tapez la commande suivante et appuyez sur Entrée

> IISRESET

OU

Ouvrez Visual Studio 2017 avec les informations d'identification d' administrateur

Tapez la commande suivante dans la console du gestionnaire de package et appuyez sur Entrée

PM > IISRESET

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

Pour moi, cela a été causé par l'installation de différentes versions de .Net Core. J'ai fait correspondre mon serveur de développement et de production et cela a fonctionné.

J'ai eu ce problème également (l'erreur s'est produite à la fois sur VS 15 et 17). Cependant sur VS15, il a renvoyé une CONNECTION_REFUSEDerreur et sur VS17, il est retournéASP.NET Core 1.0 on IIS error 502.5 .

RÉPARER

1. Accédez au répertoire de votre projet et recherchez le dossier caché .vs(il se trouve dans le répertoire du dossier des projets). (N'oubliez pas d'afficher les fichiers / dossiers cachés)

2. Fermer VS

3. Supprimer le dossier .vs
4. Démarrez VS en tant qu'administrateur (le dossier .vs sera recréé par VS)

Voici ce que j'ai pensé, et cela s'est produit récemment sur Windows 10 après l'installation d'une mise à jour. D'après ce que j'ai compris, une mise à jour de Windows Defender a été installée, qui supposait que mon "Project.dll" (un projet principal asp.net) se comportait comme un virus, il a donc été supprimé.

Donc, l'une des premières choses que je vous suggère de faire avant de commencer à installer / désinstaller des éléments est de vérifier votre "Project.dll" est là où il devrait être.

Recopiez-le à l'emplacement s'il n'y est plus.

Si vous rencontrez des difficultés pour copier le fichier, ajoutez une exclusion à votre dossier de projet dans Windows Defender . ( Apprenez à faire cela ici .)

Cela a fonctionné pour moi instantanément et je l'ai répété sur plusieurs serveurs d'application.

Pour moi, c'était que le connectionString dans Startup.cs était nul dans:

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

et il était nul car l'application ne recherchait pas dans appsettings.json la chaîne de connexion.

J'ai dû changer Program.cs en:

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

Je ne sais pas pourquoi cela a fonctionné pour moi, mais j'utilise l'authentification Windows et j'avais ce morceau de code sur mon BuildWebHostdans Program.cs:

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

Après avoir supprimé le .UserHttpSysbit, cela fonctionne maintenant et je peux toujours m'authentifier en tant qu'utilisateur de domaine.

BuildWebHost ressemble maintenant à

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

J'obtenais la même erreur et j'ai découvert que le problème était que lors de la publication sur Azure, mon fichier web.config avait été modifié de sorte que la ligne suivante se terminait comme suit:

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

Le problème pour Production est le contenu des arguments: "-argFile IISExeLauncherArgs.txt"

Il semble que ce problème sera résolu dans le prochain SDK .NET Core (actuellement en préversion), mais pour l'instant, la solution de contournement consiste à ajouter ce bloc au fichier .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>

Cela modifiera le fichier web.config et supprimera la partie problématique pour la publication.

Référence: https://github.com/aspnet/websdk/issues/242

J'espère que ça aide.

A travaillé pour moi après avoir changé la configuration de publication.

J'ai eu un problème similaire (Asp.Net Core 2.x) qui a été causé en essayant d'exécuter une application de base asp.net 32 ​​bits dans IIS sur un serveur Windows 64 bits. La cause première était que le web.config qui est généré automatiquement (si votre projet n'en inclut pas explicitement un, ce que les projets principaux asp.net ne contiennent pas par défaut) ne contient pas le chemin complet de l'exécutable dotnet. Lorsque vous installez le pack d'hébergement sur une machine 64 bits, il installera les versions 64 et 32 ​​bits de dotnet, mais le chemin sera résolu par défaut en 64 bits et votre application de base asp.net 32 ​​bits échouera à se charger. Dans votre navigateur, vous pouvez voir une erreur 502.5 et si vous regardez le journal des événements du serveur, vous pouvez voir le code d'erreur 0x80004005. Si vous essayez d'exécuter dotnet.exe à partir d'une invite de commandes pour charger votre dll d'application principale asp.net sur ce serveur, vous pouvez voir une erreur du type "BadImageFormatException" ou "

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

J'ai eu le même problème et la raison dans mon cas était que le noyau EF essayait de lire la chaîne de connexion à partir du appsettings.development.jsonfichier. Je l'ai ouvert et j'ai trouvé que la chaîne de connexion était commentée.

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

Je les ai ensuite désengagés comme ci-dessous et le problème est résolu:

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