Debogage .NET 4.0
Visual Studio 2010 et le .NET Framework 4 sont disponible en Beta 2 depuis quelques semaines. Afin de vérifier un comportement qui m’a un peu surpris, je vais les utiliser pour le débogage.
Voici le contexte : Dans un précédent billet, je parlais du deployment retail="true" pour ASP.NET en faisant référence au billet de Scott Guthrie. Je pensais que retail=true était la solution pour s’affranchir du debug=true dans tous les Web.config du serveur. C’est seulement en parti vrai car le timeout des pages ASP.NET n’est pas modifié et reste démesuré si vous avez debug=true dans votre Web.config.
Voici la preuve…
Page d’exemple
J’utilise un page exemple qui ne se termine jamais. Dans la vrai vie, nous aurons une boucle infinie plus complexes ou un bloclage quelconque. Dans tous les cas, le débogage est identique. Mon but est d’obtenir le timeout des pages ASP.NET.
<%@ Page Language="C#" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <script runat="server"> protected void Page_Load(object sender, EventArgs e) { DateTime t1 = DateTime.Now; while (true) { DateTime t2 = DateTime.Now; } } </script> <html xmlns="https://www.w3.org/1999/xhtml"> <head runat="server"> <title></title> </head> <body> <form id="form1" runat="server"> <div> </div> </form> </body> </html> |
Clin d’œil à Visual Studio 2010 et l’utilisation du zoom (CTRL+mollette de la souris) :
Cette page doit être positionnée dans un site Web utilisant un pool d’application configuré avec le Framework 4.0.
Avant de lancer WinDbg, naviguons vers notre page de test.
Lancement de WinDbg, chargement des symboles et SOS
Veillez bien à lancer Windbg en tant qu’administrateur et attachez-vous au processus W3WP.EXE en cours d’exécution (F6) :
Chargement des symboles publics :
.sympath SRV*c:\symbols*https://msdl.microsoft.com/download/symbols/ |
Chargement de SOS livré avec le .NET Framework 4.0 :
.load C:\Windows\Microsoft.NET\Framework\v4.0.21006\SOS |
Affichage des objets
Maintenant, cherchons notre page en court d’exécution
!DumpHeap -type System.Web.HttpContext |
!do 062d9d18 |
Comme il s’agit d’un objet de type TimeSpan, nous devons utiliser la méthode !DumpVC (Pour information, voici le pointeur MSDN vers SOS - https://msdn.microsoft.com/en-us/library/bb190764.aspx)
!DumpVC 532747bc 062d9dd0 |
La valeur du timeout donnée est un nombre de ticks CPU. Sachant qu’il y a 10000 ticks par millisecondes. Pour obtenir le temps en secondes, nous devons donc diviser la valeur par 10000 puis par 1000. Utilisons Windbg comme calculatrice :
?1100000000/10000/1000 |
Le timeout de la page ASPX est de 110 secondes.
Nous avons bien le comportement normal et celui par défaut décrit dans le fichier "Web.config.comments" :
Maintenant, regardons avec exactement la même démarche, ce que nous avons avec debug=true (dans Web.config) et retail=true (dans le Machine.config) :
Je vous passe toutes les copies d’écran, voici juste les deux dernières commandes :
Le timeout est de 30 000 000 secondes soit 347 jours. Effectivement, dans ce cas, nous avons tout le temps de déboguer nos pages… Et le retail=true n’a pas changé ce comportement.
La conclusion est : vérifiez que vous n’avez pas debug=true dans tous les Web.config en production même si vous avez retail=true.
Plutôt intéressant :-) Qu’en pensez-vous ?
Sebastien.