Comment obtenir les détails d’erreur d’une application ASP.NET 5 déployée sur des sites Web Azure?

J’ai une solution ASP.NET 5 avec un site Web et plusieurs bibliothèques de projets. J’utilise MVC 6 et Entity Framework 7. Localement, l’application fonctionne correctement et jusqu’à aujourd’hui, elle fonctionnait également sur Azure déployé en tant que site Web Azure.

Mais aujourd’hui, après le dernier déploiement sur Azure, j’ai reçu une erreur 500 comme celle-ci au démarrage (toujours en local):

entrer la description de l'image ici

J’ai essayé d’obtenir plus de détails par:

  • en utilisant des diagnostics de middleware
  • append les parameters customError / httpError dans le fichier web.config
  • télécharger la page DetailedError générée

Il semble que l’erreur / l’exception se produit pendant l’étape de démarrage / configuration, mais je reçois toujours la page d’erreur générique sans détails. Même la version générée sur le serveur (dossier DetailedErrors):

entrer la description de l'image ici

J’ai activé le suivi des demandes ayant échoué mais toujours aucune information utile:

entrer la description de l'image ici

Même si je décode le code dans Startup / Configure et ajoute un try / catch comme suggéré, j’ai eu la même erreur sans détails. Cela semble être un problème de configuration / compilation mais difficile à déboguer sans aucune information.

Dans RC1 (à partir de beta8, peut-être), on devrait apparemment utiliser:

app.UseDeveloperExceptionPage(); 

.. qui apparemment ne fonctionne que si app.Properties["host.AppMode"] est "development" .

Mais cela n’a pas fonctionné pour moi. Le message d’erreur que je recevais était spécifiquement “Une erreur s’est produite lors du démarrage de l’application” , j’ai constaté qu’aucune des configurations données ne résoudrait ce problème car l’erreur se produit avant l’exécution des configurations.

D’une manière ou d’une autre, le dossier cible de publication doit avoir été corrompu lors de la publication car j’ai constaté que la suppression de l’intégralité du répertoire de déploiement et la republication résolvaient le problème .

Sinon, voici la référence: http://docs.asp.net/en/latest/fundamentals/diagnostics.html

Les erreurs qui surviennent au démarrage d’une application ASPNET5 sont vraiment difficiles à détecter lors de l’exécution de l’application dans Azure (au moins avec la version bêta 3). Espérons qu’ils trouvent un moyen d’améliorer l’expérience. Je devais recourir à la mise à nu de mon démarrage et append du code ligne par ligne jusqu’à ce que l’échec se produise (dans mon cas, il s’agissait d’une variable d’environnement manquante).

J’ai également utilisé un code comme celui-ci (pour le débogage uniquement), ce qui peut aider selon l’endroit où l’erreur se produit:

 public void Configure(IApplicationBuilder app, IHostingEnvironment env ) { try { // Add MVC to the request pipeline. app.UseMvc(routes => { routes.MapRoute( name: "default", template: "{controller}/{action}/{id?}" ); }); } //exceptions in startup are really bad when running in azuree, all you will get is an internal server error //this code will write the exception message to the browser instead. Only use for debugging!!! catch (Exception ex) { app.Run(async context => { context.Response.ContentType = "text/plain"; await context.Response.WriteAsync(ex.Message); }); } } 

Mise à jour 27/10/2016 Beaucoup de choses ont changé depuis ma réponse initiale. Les dernières orientations sont affichées ici:

https://docs.asp.net/en/latest/fundamentals/hosting.html

Alors, ajoutez:

.CaptureStartupErrors (true) et .UseSetting (WebHostDefaults.DetailedErrorsKey, “true”) sur votre WebHostBuilder comme ceci:

  var host = new WebHostBuilder() .CaptureStartupErrors(true) .UseSetting(WebHostDefaults.DetailedErrorsKey, "true") .UseKestrel() .UseContentRoot(Directory.GetCurrentDirectory()) .UseIISIntegration() .UseStartup() .Build(); 

Vous devez définir la propriété des parameters d’application ASPNET_DETAILED_ERRORS sur true dans le fichier web.config .

Exemple de mon fichier web.config édité:

                 

J’ai rencontré exactement la même erreur avec une application Web exécutant dnx-clr-win-x64.1.0.0-rc1-update1. J’ai effectué le déploiement directement à partir de Visual Studio 2015 Enterprise Update 1. J’ai constaté que le site fonctionnait chaque fois que je faisais le premier déploiement sur une application Web nouvellement créée. À partir du deuxième déploiement (même lors du déploiement du même contenu exact), j’ai commencé à voir Internal Server Error 500. Cela m’a amené à la solution suivante:

Activer “Supprimer les fichiers supplémentaires à la destination” dans l’assistant de publication de Visual Studio l’a corrigé pour moi.

entrer la description de l'image ici

J’ai eu le même problème et j’ai passé beaucoup de temps à essayer de creuser dans les journaux d’erreurs, etc. (toutes les autres solutions données ci-dessus). Aucun d’entre eux ne donne la moindre idée de ce qui ne va pas.

Ce que j’ai fait qui m’a aidé à voir finalement l’erreur était simplement d’essayer de publier sur un IIS local (après tout azure web-app exécute votre dnx sur IIS en interne).

Je pourrais alors immédiatement voir qu’il y a une erreur lorsque IIS essaie de comstackr la source. (dans mon cas était un paquet mal formé de nuget).

Donc en bref:

Recréez ce qui se passe sur une application Web Azure en publiant sur IIS local.

Créez un web.config dans votre dossier wwwroot avec ce contenu:

      

Avez-vous vérifié dans le fichier eventlog.xml? C’est dans le répertoire D: \ home \ LogFiles. Vous pouvez l’afficher à partir du site Kudu de votre application ou utiliser l’extension Azure Websites Event Viewer.

Avez-vous essayé d’utiliser le débogage distant de l’application Web Azure? Il y a des chances qu’il y ait des exceptions qui sont responsables de cela et si vous regardez votre fenêtre DEBUG OUTPUT, vous pourrez peut-être voir quelle exception se produit, puis modifier les parameters de Visual Studio pour que cette exception se produise. Consultez cet article pour savoir comment déboguer à distance – http://blogs.msdn.com/b/webdev/archive/2013/11/05/remote-debugging-a-window-azuree-web-site-with-visual- studio-2013.aspx