IIS ne parvient pas à exécuter le site ASP.NET Core - Erreur HTTP 502.5
Nous avons une machine Windows 2012 R2. J'avais un site ASP.NET Core existant sur lequel fonctionnait un site ASP.NET Core publié.
Cependant, lorsque j'ai publié à nouveau sur le site aujourd'hui, un mois plus tard, après avoir apporté des modifications, je ne peux plus accéder au site et le message d'erreur suivant s'affiche dans mon navigateur.
Erreur HTTP 502.5 - Échec du processus
Pour plus d'informations, visitez le site: http://go.Microsoft.com/fwlink/?LinkID=808681
Si je me connecte au serveur et que je clique sur le fichier exe de mon répertoire déployé, il ouvre une invite de commande et affiche mon site sur le port 5000. Si j'accède au site sur http: // localhost: 50 cela fonctionne parfaitement, donc le problème est lié à IIS et non au site lui-même.
Si je me connecte au serveur, les événements suivants apparaissent dans Windows EventViewer
L'application 'MACHINE/WEBROOT/APPHOST/DEFAULT WEB SITE/MySite' avec la racine physique 'D:\Sites\MySite \' n'a pas pu démarrer le processus avec la ligne de commande '"% LAUNCHER_PATH%"% LAUNCHER_ARGS%', ErrorCode = '0x80070002: 0.
Lorsque je visitais le lien dans le message d'erreur du navigateur, il mentionnait la réinstallation du pack .net Core Hosting, ce que j'ai fait. Cependant, le message d'erreur dans le navigateur est le même.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore requestTimeout="02:00:00" processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
</system.webServer>
</configuration>
Lorsque je regarde mon dossier de journal d'applications, un fichier stdout est créé chaque fois qu'il tente d'accéder à ce site, mais à chaque fois, il est de taille 0 Ko et contient un contenu vide.
Pourquoi IIS refuse-t-il de travailler soudainement là où il fonctionnait auparavant mais que l'application fonctionne si j'accède directement à l'exe compilé?
Votre problème est un mauvais fichier web.config:
<aspNetCore requestTimeout="02:00:00"
processPath="%LAUNCHER_PATH%"
arguments="%LAUNCHER_ARGS%"
stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout"
forwardWindowsAuthToken="false" />
Le chemin% LAUNCHER_PATH% n'existe pas sur votre système, il n'est même pas valide. Cela devrait être quelque chose comme:
<aspNetCore requestTimeout="02:00:00"
processPath=".\yourAppName.exe"
arguments="somePossibleArgument"
stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout"
forwardWindowsAuthToken="false" />
Notez que le fichier web.config est complètement ignoré si l'application est lancée à partir de la ligne de commande. C'est pourquoi vous ne recevez pas l'erreur.
J'ai eu ce même problème, mon problème était IIS n'a pas pu obtenir le chemin d'accès à Dotnet. J'ai pu le réparer en spécifiant le chemin d'accès au fichier dotnet.exe
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="C:\Program Files\dotnet\dotnet.exe" arguments=".\your-project.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout"/>
</system.webServer>
</configuration>
Mon problème était que le processus ne voulait pas démarrer en raison d'une séquence d'échappement non valide dans mon fichier appsettings.json.
J'utilise dotnet pour exécuter la dll Web api Web ASPNET Core 2 publiée. Le problème a été révélé en ouvrant une invite de commande et en naviguant dans le répertoire où se trouvent les fichiers du site. Une fois là-bas, j'ai lancé la commande:
dotnet mySite.dll
(remplacez mySite.dll par la DLL principale de votre application. Assurez-vous également que la version correcte de l'ensemble Hébergement .NET Core Windows Server est déjà installée).
En appuyant sur Entrée, il s'est immédiatement écrasé, donnant le retour exact de ce qui n'allait pas dans la fenêtre de la console. C'est un excellent moyen de déterminer votre ou vos erreurs de démarrage si vous rencontrez des problèmes similaires.
J'ai eu un problème similaire. Je viens de suivre les étapes de dépannage: Check the system event log for error messages et j'ai trouvé ce qui suit dans l'observateur d'événements, Application 'MACHINE/WEBROOT/APPHOST/[MyFolder]' with physical root 'C:\inetpub\wwwroot\[MyFolder]\' failed to start process with commandline 'dotnet .\MyApp.dll', ErrorCode = '0x80004005 : 80008083.
J'ai alors relancé dotnet .\MyApp.dll à partir d'un terminal et j'ai obtenu la réponse:
It was not possible to find any compatible framework version
The specified framework 'Microsoft.AspNetCore.App', version '2.1.1' was not found.
- Check application dependencies and target a framework version installed at:
\
- Alternatively, install the framework version '2.1.1'.
Donc, la raison est la même que celle donnée par jv_, vous n'avez simplement pas de version compatible du framework installée. J'ai fini par utiliser le mode de déploiement "autonome" et cela a fonctionné.
J'ai rencontré le même problème lorsque j'ai déployé mon application. Il y avait plusieurs problèmes de mon côté :)
J'ai parcouru cette page très attentivement: ASP.NET Core: Publication sur IIS
Tout d’abord, je n’avais pas toutes les pièces du pack d’hébergement .NET Core Windows Server installées. J'ai fini par faire un déploiement dépendant de Fremework au lieu d'un déploiement autonome. Nous avons beaucoup d'applications et nous ne voulons pas/n'avons pas besoin de chacune sur leur propre version de .net core. Il y aurait beaucoup trop de versions de .net sur la boîte.
Notez également que si vos administrateurs effectuaient des mises à jour/mises à niveau sur le serveur, ils auraient peut-être ajouté votre installation ASP.NET Core (voir la section ASP.NET Core: Publication sur IIS )
Ensuite, j'ai dû réparer mon web.config ... voici mon web.config publié: je n'ai pas publié en tant que * .exe, j'ai fait * .dll (notez la valeur de mes arguments). En outre, mon processusPath est défini sur "dotnet".
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\DT.Web.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
</system.webServer>
</configuration>
Assurez-vous également que vos options project.json sont compatibles avec votre environnement de serveur (voir section ASP.NET Core: Publication sur IIS dépannage).
Voici une copie de la de mon project.json si cela peut vous aider:
{
"version": "2.0.1.0",
"dependencies": {
"DT.Common": "2.*",
"DT.Configuration": "2.*",
"DT.Services": "2.*",
"DT.Web.ViewModels": "2.*",
"Microsoft.ApplicationInsights.AspNetCore": "1.0.2",
"Microsoft.AspNetCore.Authentication": "1.1.0",
"Microsoft.AspNetCore.Authentication.Cookies": "1.1.0",
"Microsoft.AspNetCore.Authentication.OpenIdConnect": "1.1.0",
"Microsoft.AspNetCore.Diagnostics": "1.1.0",
"Microsoft.AspNetCore.Mvc": "1.1.0",
"Microsoft.AspNetCore.Razor.Tools": {
"version": "1.1.0-preview4-final",
"type": "build"
},
"Microsoft.AspNetCore.Routing": "1.1.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.1.0",
"Microsoft.AspNetCore.Server.IISIntegration.Tools": {
"version": "1.1.0-preview4-final",
"type": "build"
},
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
"Microsoft.AspNetCore.Server.Kestrel.Https": "1.1.0",
"Microsoft.AspNetCore.Session": "1.0.0",
"Microsoft.AspNetCore.StaticFiles": "1.1.0",
"Microsoft.Extensions.Caching.SqlServer": "1.0.0",
"Microsoft.Extensions.Configuration.Abstractions": "1.1.0",
"Microsoft.Extensions.Configuration.FileExtensions": "1.1.0",
"Microsoft.Extensions.Configuration.Json": "1.1.0",
"Microsoft.Extensions.Logging.Console": "1.1.0",
"Microsoft.Extensions.Logging.Debug": "1.1.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0",
"Microsoft.Graph": "1.1.1",
"Microsoft.IdentityModel.Clients.ActiveDirectory": "3.13.6"
},
"tools": {
"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.1.0-preview4-final",
"Microsoft.AspNetCore.Razor.Tools": {
"version": "1.1.0-preview4-final",
"imports": "portable-net45+win8+dotnet5.6"
},
"Microsoft.Extensions.Caching.SqlConfig.Tools": "1.1.0-preview4-final"
},
"frameworks": {
"netcoreapp1.1": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
],
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.1.0",
"type": "platform"
}
}
}
},
"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true
},
"runtimeOptions": {
"configProperties": {
"System.GC.Server": true
}
},
"publishOptions": {
"include": [
"wwwroot",
"views/**/*.cshtml",
"appsettings.json",
"appsettings.*.json",
"web.config"
]
},
"scripts": {
"prepublish": [ "bower install", "gulp buildprod" ],
"postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
}
}
J'ai eu le même problème avec Visual Studio transformant le fichier web.config et changeant le processPath et les arguments. Comme indiqué sur le site Microsoft , vous pouvez ajouter l'exclusion dans le fichier project.csproj:
<PropertyGroup>
<IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>
Cela a pris soin de mon problème avec le changement de la valeur du chemin lors de la publication, mais le problème persiste, Visual Studio le changeant tout seul lors du débogage.
Problème: lorsque je déploie l'API Web principale d'aspnet net, le chemin processprath est défini sur dotnet. L'application ne démarre pas et l'observateur d'événements affiche l'erreur ci-dessus.
Solution:
L'identité du pool d'applications doit être configurée pour charger le profil.
Accédez à: Pool d'applications -> NetCore (votre pool) -> Paramètres avancés -> Charger le profil utilisateur ----> Définissez ceci sur true
J'ai vérifié que le passage à false recrée l'erreur et que le retour à true l'a résolue.
Pour moi, la solution consistait simplement à installer .Net Core 2.2 SDK et cela a fonctionné.
Mon projet fonctionnait bien en développement, mais après le déploiement/la publication en production sur le Web, il jetait 502.5 Process Failure.
La raison s’est avérée être que j’avais mis à jour en utilisant Microsoft.AspNetCore.All 2.0.5 à 2.0.6. A bien fonctionné après avoir retourné la version.
Cela m'a complètement rendu fou étant donné que j'ai essayé toutes les corrections possibles trouvées en ligne mais que rien ne fonctionnait pour moi. Jusqu'à ce que je découvre que le problème était que j'avais un espace dans mon nom de projet: App WebAPI.dll. Ainsi, lorsque "dotnet.\App WebAPI.dll" tente de s'exécuter, il échoue car il essaie réellement d'exécuter "dotnet.\App" et d'oublier la deuxième partie après l'espace. Renommer mes noms de solutions et de projets pour supprimer des espaces (AppWebAPI) a résolu mon problème. J'espère que ce correctif fait gagner du temps aux gens qui essaient de comprendre le problème.
Je suis confronté au même problème et rien de ce fil ne fonctionne pour moi. J'ai donc regardé dans Windows Event Viewer et découvert que l'utilisateur ne disposait pas des autorisations suffisantes pour créer/modifier une base de données car j'utilisais les migrations de base de base EF. La fixation de l’autorisation a résolu ce problème.
Par conséquent, je suggérerais de passer en revue vos événements d’application et d’espérer que vous obtiendrez la cause première de votre erreur.
Je souhaitais pouvoir exécuter mon API basée sur .Net Core à partir de IIS à partir de mon répertoire de développement sans me battre avec le fichier web.config. Visual Studio contrôle le fichier web.config en fonction des paramètres du profil de projet. Vous devez simplement ajouter un profil IIS à votre début de débogage pour que VS sache quoi faire avec votre web.config. Les instructions sont ici:
Maintenant, je peux juste coder un peu, compiler et actualiser mon navigateur sans attendre le lancement du navigateur et sans perdre ma chaîne de requête à chaque fois. En cliquant sur Déboguer attache automatiquement VS à IIS pour le débogage, ce qui signifie qu'il n'est plus nécessaire d'attacher manuellement le débogueur à w3wp, ce qui m'ennuie depuis des lustres. Parfait!
Pour référence, VS change mon web.config de manière dynamique en ceci:
<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout">
<environmentVariables />
Mais, je ne voudrais pas coder cela dans le web.config, laissez simplement VS le gérer. :)
J'avais le même problème, sauf que j'avais mis à jour Visual Studio sur mon environnement de développement et que le serveur avait besoin d'une mise à jour d'exécution .NetCore. Une fois que j'ai mis à jour le run-time sur le serveur, j'étais prêt à recommencer.
Je suppose que mon manque d'expérience avec la mise à jour de VS 2017 était mon problème ;-)
Après un certain temps, j’ai compris que le problème était lié à un problème de propriété
appsettings.json
fichier.
J'ai une propriété qui s'appelle Version. Le format est comme ça:
"Version": "1.0.6",
Sur le serveur, notre équipe de support n’a pas envisagé ce format et il se présentait ainsi:
"Version": 1.0.6,
et IIS a fait face à une erreur 502.5.
J'ai pu voir le journal des événements de l'application et cela m'a aidé.
Lorsque l'équipe sur laquelle j'ai travaillé a eu ce problème, quelqu'un a simplement créé le projet avec Visual Studio et a compressé le dossier bin.
Vous devez exécuter la commande dotnet publish afin que les tâches msbuild construisent correctement votre fichier web.config. Il doit remplacer les variables% LAUNCHER_PATH% "et"% LAUNCHER_ARGS%.