Debug dans Azure : c’est même trop facile

Le développement dans le cloud, et en particulier dans Azure, simplifie grandement les choses. Mais parfois, quand il y a un problème non reproductible en local, on se met à regreter le serveur facilement accessible “à l’ancienne”. Je vous rassure, ce sentiment d’impuissance va disparaître dans quelques lignes.

Voici un cas concret que j’ai rencontré il y a quelques semaines. Je travaillais sur une application ASP.Net MVC, tout se passait bien : sources dans VSO, build auto et déploiement sur Azure. Mais lorsque l’on accède au site, grosse erreur 500. En gros, il y a un problème sur le serveur, côté C#, mais je n’en saurais pas plus comme cela.

image

Comment faire pour sortir de ce problème sachant que notre site est sur une machine que l’on ne connait pas ? Et bien tout simplement en se laissant guider par Visual Studio. Au lieu de passer par un déploiement automatique, je décide de faire un déploiement manuel en staging. En plus de déployer, je vais pouvoir ajouter quelques options qui vont m’aider à trouver le problème :

  • Activation des traces intellitrace,
  • Activation du remote debug.

image

J’active seulement le premier sachant que je peux revenir à tout moment dessus. De plus, Visual Studio me garde le profil au chaud pour une future session de débug.

image

Une fois le déploiement terminé et lorsque j’ai reproduit l’erreur, je peux aller chercher les traces via le server explorer.

image

Je n’ai plus qu’à choisir l’exception et je tombe sur la réponse : la page de layout n’a pas été déployée. En cliquant sur l’exception, j’ai même la possibilité de voir la pile d’appel complète.

image

Effectivement le fichier n’est pas pris en compte au moment de la compilation :

image

Je change l’état, je déploie de nouveau et tout fonctionne Smile

@+

Pas de commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *