ASP.NET Core 1.0 sur IIS erreur 502.5
Je viens de mettre à jour mon serveur (Windows 2012R2) avec .Net Core 1.0 RTM 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
Cela fonctionnait auparavant avec la version RC2. Je ne sais pas ce qui pourrait aller de travers.
Ceci est tout l'observateur d'événement dit:
Failed to start process with the commandline 'dotnet .\MyWebApp.dll'. Error code = '0x80004005'.
le pire, c’est que les journaux d’application sont vides! Je veux dire, 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 quand ce n'est pas enregistré ??
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’avais précédemment compilé l’application sans aucune plate-forme à l’esprit, elle m’a donné la version dll qui ne fonctionne que si l’hôte cible a le paquet .Net Core Windows Hosting installé. Dans mon cas c'était installé et c'était bon.
Après que l'application ne fonctionne plus, j'ai décidé de la compiler en tant qu'application console avec win7-x64 comme runtime. Cette fois, au moment où j'ai exécuté la exe de mon application sur le serveur, une erreur s’est produite lors de l’ajout d’une dll manquante:
The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing
Cette dll provient de Universal C Runtime et est incluse dans le Visual C++ redistribuable pour Visual Studio 2015.
J'ai essayé d'installer ce paquet (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. C'était peut-être la raison derrière cela, mais je ne peux toujours pas le dire avec certitude.
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:
"L'infrastructure spécifiée 'Microsoft.NETCore.App', version '1.0.1' est introuvable. - Vérifiez les dépendances de l'application et ciblez une version de l'infrastructure installée à l'emplacement suivant: C:\Program Files\dotnet\shared\Microsoft.NETCore.App - Les versions suivantes sont installées: 1.0.0 - Vous pouvez également installer la version de framework '1.0.1'.
Comme vous pouvez le constater, la mauvaise version de NET Core a été installée sur mon serveur. J'ai pu exécuter mon application après avoir désinstallé la version 1.0.0 précédente et installé la version 1.0.1 correcte.
J'ai eu le même problème, dans mon cas, la permission de l'identité de l'utilisateur de mon pool d'applications était insuffisante, sur la page Publication sur IIS de la documentation asp.net, deux raisons sont à l'origine de cette erreur. :
- Si vous avez publié une application autonome, confirmez que vous n'avez pas défini de plateforme dans
buildOptionssurproject.jsonen conflit avec le RID de publication. Par exemple, ne spécifiez pas une plate-forme 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 consignées ci-dessus sur le serveur. - Vérifiez l'attribut
processPathsur l'élément<aspNetCore>dans web.config pour confirmer qu'il s'agit dedotnetpour une application portable ou.\My_application.exe pour une application autonome. - Pour une application portable, il est possible que
dotnet.exene soit pas accessible via les paramètres PATH. Confirmez queC:\Program Files\dotnet\existe dans les paramètres System PATH. - Pour une application portable, il est possible que
dotnet.exene soit pas accessible pour l'identité d'utilisateur du pool d'applications. Confirmez que l'identité de l'utilisateur AppPool a accès au répertoireC:\Program Files\dotnet. - Vérifiez que vous avez correctement référencé le middleware d'intégration IIS en appelant la méthode
.UseIISIntegration()de l'applicationWebHostBuilder()de l'application. - Si vous utilisez la méthode d'extension
.UseUrls()lorsque vous vous auto-hébergez avec Kestrel, vérifiez qu'elle est positionnée avant la méthode d'extension.UseIISIntegration()surWebHostBuilder()..UseIISIntegration()doit définir la variableUrldu 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 modifiée 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 disposant des droits suffisants: 
Je travaille avec une réinitialisation matérielle de IIS (je venais juste d'installer le pack d'hébergement).
Il s'avère que le simple fait d'appuyer sur 'Redémarrer' dans IIS Manager ne suffit pas. Je viens juste d'ouvrir une invite de commande et de taper 'iisreset'
J'ai eu le même problème.
Pour 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éé des journaux sous-dossier dans le dossier racine MyWebService.
Après avoir redémarré IIS et essayé d'exécuter l'API, une erreur s'est produite et Core Runtime manquait. Après avoir téléchargé l’installation de DotNetCore.1.0.5_1.1.2-Windows, l’erreur disparue.
J'ai eu le même problème lors de la publication de l'application Web. Si quelqu'un a toujours ce problème, il est résolu en changeant {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" en "version": "1.1.1" et tout fonctionnait bien
Avait le même problème et toutes les solutions ne fonctionnaient pas. J'ai trouvé ce petit bijou et pensé que je transmettrais si cela aidait quelqu'un d'autre. Installez sur Server 2012 R2 en obtenant l'erreur manquante DLL, essayez de réinstaller VS C++ 2015 et obtenez une erreur. Fix est de faire ce qui suit:
Le fichier C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msu a des problèmes d’installation. Ouvrez la commande admin Invite do:
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.
RÉSOLU Je viens de faire face au même problème aujourd'hui lors du déploiement vers 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 à le résoudre 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 fichier Web.config généré ressemble à ceci: <aspNetCore processPath="dotnet" arguments=".\Yodlee.dll -argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
VEUILLEZ essayer de modifier la configuration ci-dessus dans Visual Studio solution<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />
Dans notre nouveau dossier de déploiement, le fichier 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 vous aidera.
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 1.1.2 .net à partir d'ici sur mon serveur de production: https://www.Microsoft.com/net/download/core#/runtime
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'avais un problème similaire, et pour citer Sherlock Holmes: "quand vous avez éliminé l'impossible, tout 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 .NET Framework 4.6.2 et cela a fonctionné.
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 fichier .csproj:
<PropertyGroup>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
Dans mon cas, après avoir installé AspNetCore.2.0.6.RuntimePackageStore_x64.exe et DotNetCore.2.0.6-WindowsHosting.exe, il me faut redémarrer le serveur pour que cela fonctionne sans 502 passerelles défectueuses et erreur proxy.
MISE À JOUR:
Vous pouvez l’utiliser sans redémarrer d’une autre manière: https://stackoverflow.com/a/50808634/3634867
J'ai eu la même erreur en question, avec les mêmes problèmes que ceux décrits par VSG24 dans 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 (ainsi que les conditions préalables et toutes les autres mises à jour liées - lisez attentivement les instructions d'installation sur le site Web de Microsoft):
- KB2919355
- KB2999226
J'espère que ça 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.config avec la valeur appropriée de l'attribut 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" ... />
Je l'ai résolu en ajoutant "l'autorisation de modification" à l'application du site, mappé sur le répertoire physique, puis sélectionné l'utilisateur Windows pouvant avoir accès à ce dossier racine. (Réseau privé).
J'avais besoin d'installer la dernière version .net Core trouvée ici . Pas besoin de redémarrer le site ou le serveur
Pour moi, cela est dû au fait que différentes versions de .Net Core sont installées. J'ai assorti mon serveur de production et de développement et cela a fonctionné.
Partageant que dans mon cas, cette erreur était due au fait que j'avais oublié de mettre à jour project.json avec:
"buildOptions": {
"emitEntryPoint": true
}
Ouvrir invite de commande avec administrateur informations d'identification
Tapez la commande suivante et appuyez sur Entrée
> IISRESET
OR
Ouvrez Visual Studio 2017 avec administrateur informations d'identification
Tapez la commande suivante dans Package Manager Console et appuyez sur Entrée
PM> IISRESET
PM> IISRESET
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted
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 d'accès à dotnet.exe dans le fichier web.config pour que l'application fonctionne correctement, comme l'a indiqué @danielyewright dans son commentaire github . Cela fonctionne après avoir défini le chemin.
Merci
Dans mon cas, il y avait un problème avec la version de 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'ai eu ce problème aussi (L'erreur s'est produite à la fois sur VS 15 et 17). Cependant, sur VS15, il a renvoyé une erreur CONNECTION_REFUSED et sur VS17, il a renvoyé ASP.NET Core 1.0 on IIS error 502.5.
FIX
Accédez au répertoire de votre projet et localisez le dossier caché
.vs(situé dans le dossier des projets). (N'oubliez pas de montrer les fichiers/dossiers cachés)Fermer VS
- Supprimer le dossier .vs
- Démarrer VS en tant qu'administrateur (le dossier .vs sera recréé par VS)
J'ai changé les options de profil pour cela et ça marche !!!
Peut-être devriez-vous changer ces deux options:
- Mode de déploiement
- Runtime cible
J'avais la même erreur et j'ai découvert que le problème était que, lors de la publication dans Azure, mon fichier web.config avait été modifié et que la ligne suivante était terminée. comme ça:
<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 traité dans le prochain Kit de développement .NET Core SDK (actuellement en aperçu), mais pour l’instant, la solution consiste à ajouter ce bloc au fichier .csproj:
<Target Name="bug_242_workaround" AfterTargets="_TransformWebConfig">
<Exec Command="powershell "(Get-Content '$(PublishDir)Web.config').replace(' -argFile IISExeLauncherArgs.txt', '') | Set-Content '$(PublishDir)Web.config'"" />
</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.
Voici ce que j'ai pensé, et cela s'est produit récemment sous 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. Elle supposait que mon "Project.dll" (un projet principal asp.net) se comportait comme un virus et qu'il a donc été supprimé.
Donc, une des premières choses que je vous suggère de faire avant de commencer l’installation/la désinstallation de fichiers est de vérifier que votre "Project.dll" se trouve à l’endroit où il devrait se trouver
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 ça ici .)
Cela a fonctionné instantanément pour moi et je l'ai répété sur plusieurs serveurs d'applications.
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 fichier appsettings.development.json. 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 alors engagés comme ci-dessous et le problème résolu:
{
"ConnectionStrings": {
"DefaultConnection": "Server=vaio;Database=Goldentaurus;Trusted_Connection=True;",
"IdentityConnection": "Server=vaio;Database=GTIdentity;Trusted_Connection=True;"
}
}
J'avais un problème similaire (Asp.Net Core 2.x) provoqué par une tentative d'exécution d'une application principale asp.net 32 bits dans IIS sur un serveur Windows 64 bits. La cause première était que le fichier web.config généré automatiquement (si votre projet n'en inclut pas explicitement, les projets principaux asp.net ne le faisant pas par défaut) ne contient pas le chemin d'accès complet à l'exécutable dotnet. Lorsque vous installez le pack d'hébergement sur un ordinateur 64 bits, il installera les versions 64 et 32 bits de Dotnet, mais le chemin d'accès sera résolu par défaut en 64 bits et votre application principale asp.net 32 bits échouera. Une erreur 502.5 peut s'afficher dans votre navigateur. Si vous consultez le journal des événements du serveur, le code d'erreur 0x80004005 peut s'afficher. Si vous essayez d'exécuter dotnet.exe à partir d'une invite de commande pour charger votre dll d'application principale asp.net sur ce serveur, une erreur telle que "BadImageFormatException" ou "une tentative de chargement d'un programme au format incorrect" peut s'afficher. Le correctif qui a fonctionné pour moi a été d'ajouter un fichier web.config à mon projet (et son déploiement) et, dans ce fichier web.config, de définir le chemin d'accès complet à la version 32 bits de dotnet.exe.
<?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>
Pour moi, c’était que le connectionString dans Startup.cs était null dans:
services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
et il était nul parce que l'application ne cherchait pas dans appsettings.json pour la chaîne de connexion.
Devait changer Program.cs pour:
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 BuildWebHost dans Program.cs:
.UseStartup<Startup>()
.UseHttpSys(options =>
{
options.Authentication.Schemes =
AuthenticationSchemes.NTLM | AuthenticationSchemes.Negotiate;
options.Authentication.AllowAnonymous = false;
})
.Build();
Après avoir supprimé le bit .UserHttpSys, il 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();
Travaillé pour moi après avoir changé la configuration de publication.
