2009-11-02 4 views
1

J'ai hérité d'une application ASP.NET qui génère des pages avec des valeurs viewstate massives. Pendant que je travaillais dessus, j'ai supposé que je serais capable d'utiliser Firebug pour inspecter la sortie et définir les points d'arrêt dans le script côté client résultant. Ce que j'ai trouvé à la place est que chaque fois que Firebug rencontre un grand viewstate, il se bloque complètement lors du rendu de l'onglet Script, ce qui rend presque impossible la définition et l'utilisation des points d'arrêt.Problèmes lors de l'utilisation de Firebug pour afficher le script sur une page ASP.NET avec une très grande taille VIEWSTATE

Ce que je vois dans la sortie est quelque chose de très semblable à ceci:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > 
<HTML> 
<HEAD> --snipped-- </HEAD> 
<body> 
    <form name="..." method="post" action="..." id="..."> 
    <input 
     type="hidden" 
     name="__VIEWSTATE" 
     id="__VIEWSTATE" 
     value="/V4dAUdVmVyc2lvbiAzLjAsIGJ1aWxkIDMxIChlbi1VUylkAgUPFgIfAGVkAgsPDxYCHwAFC1RpbSBCb29ybWFuZGQCDw8QDxYCHgtfIURhdGFC 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > 
<HTML> 
<HEAD> --snipped-- </HEAD> 
<body> 
    <form name="..." method="post" action="..." id="..."> 
    <input 
     type="hidden" 
     name="__VIEWSTATE" 
     id="__VIEWSTATE" 
     value="/V4dAUdVmVyc2lvbiAzLjAsIGJ1aWxkIDMxIChlbi1VUylkAgUPFgIfAGVkAgsPDxYCHwAFC1RpbSBCb29ybWFuZGQCDw8QDxYCHgtfIURhdGFC 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > 
<HTML> 
<HEAD> --snipped-- </HEAD> 
<body> 
    <form name="..." method="post" action="..." id="..."> 
    <input 
     type="hidden" 
     name="__VIEWSTATE" 
     id="__VIEWSTATE" 
     value="/V4dAUdVmVyc2lvbiAzLjAsIGJ1aWxkIDMxIChlbi1VUylkAgUPFgIfAGVkAgsPDxYCHwAFC1RpbSBCb29ybWFuZGQCDw8QDxYCHgtfIURhdGFC 

En d'autres termes, Firebug obtient la moitié de la valeur viewstate, puis recommence à partir du haut, ce qui rend tout de la déclaration DOCTYPE le même endroit dans le viewstate.

Bien que je reconnaisse (et je travaille sur) le fait qu'il y ait un problème avec la façon dont cette application utilise viewstate, je suis surpris par la gestion de la sortie par Firebug. J'ai les dernières versions de Firefox et Firebug. Y at-il un paramètre que je peux modifier pour rendre l'onglet de script rendu correctement? Quelqu'un d'autre a-t-il eu des problèmes avec Firebug et ASP.NET viewstate?

Répondre

0

Bien qu'il ne traite pas le problème ViewState sous-jacent, j'ai implémenté la solution de contournement suivante dans la page spécifique où j'ai besoin d'utiliser Firebug. Notez que je ne recommande pas SessionPageStatePersister comme solution ultime (stocker cet énorme viewstate sur le serveur ne fait que déplacer le problème) mais j'ai pensé partager la solution qui m'a permis d'aller de l'avant.

#if DEBUG 
    // When debugging, it is useful to not have the large viewstate values 
    // output to the browser. 
    protected override System.Web.UI.PageStatePersister PageStatePersister 
    { 
     get 
     { 
      return new SessionPageStatePersister(this); 
     } 
    } 
#endif 

Cela garantit que seule la sortie je me soucie de passe au navigateur quand je suis débogage, mais aussi ne change pas le comportement de viewstate de la production actuelle.

0

Avez-vous essayé d'autres outils de débogage JavaScript? Je sais que Chrome et Safari ont des débogueurs de scripts intégrés ou qu'il existe Venkman, le plug-in FireFox.

+0

Puisque je posais des questions sur Firebug, certaines personnes pourraient dire qu'une réponse de «utiliser un outil différent» n'est pas une réponse utile. Cependant, je pense que c'est une partie importante du dépannage, et dans ce cas, cela a conduit à un résultat très intéressant: le problème viewstate ne se produit pas dans le débogueur Venkman! En outre, merci de me présenter un nouvel outil. Il ne couvrira pas tout ce que j'utilise Firebug, mais il semble être très bon pour la tâche pour laquelle il a été conçu. –

Questions connexes