Dois-je ignorer l'erreur de visualisation occasionnelle non valide?
De temps en temps (une fois par jour environ), nous voyons les types d'erreurs suivants dans nos journaux pour une application ASP.NET 3.5
- État de vue non valide
- Argument de publication ou de rappel non valide
S'agit-il de quelque chose qui "se produit simplement" de temps en temps avec une application ASP.NET? Quelqu'un recommanderait-il que nous passions beaucoup de temps à essayer de diagnostiquer la cause des problèmes?
En fait ça dépend. Un état de vue non valide peut se produire pour diverses raisons.
- Viewstate est trop grand et n'a pas terminé le rendu avant qu'un utilisateur ne provoque une publication sur la page. Le correctif consiste généralement à désactiver tous les contrôles qui déclenchent des publications et à les activer côté client une fois le chargement de la page terminé - voir http://blogs.msdn.com/tom/archive/2008/03/14/validation- of-viewstate-mac-failed-error.aspx
- Vous utilisez des MAC viewstate (et vous devriez l'être, pour des raisons de sécurité) mais vous n'avez pas défini de clé machine et le pool d'applications a recyclé en générant une nouvelle. N'oubliez pas de définir un ViewStateUserKey.
- Quelqu'un utilise une ancienne version de IE sur le mac où il tronque les champs de formulaire masqués. Dans ce cas, vous devrez déplacer viewstate hors de la page dans état de session =.
- Les problèmes de Viewstate MAC indiquent généralement que vous êtes dans une batterie de serveurs Web et que vous avez oublié de définir une clé machine dans web.config. Cependant, si vous avez fait cela, c'est probablement quelqu'un qui essaie de faire de mauvaises choses (des bots publiant des commentaires, quelqu'un essayant de déclencher des événements pour des contrôles désactivés, etc.) La cause de ceux-ci doit être recherchée, ne serait-ce que pour exclure les problèmes de sécurité potentiels.
Quoi que vous fassiez ne le faites pas désactivez la vue d'état ou la validation d'événement.
Un problème peut être lié aux routeurs des utilisateurs qui tronquent les champs du formulaire. La solution consiste à définir MaxPageStateFieldLength sur un petit nombre (comme 100) dans web.config et le ViewState est divisé en petits morceaux. C'est très simple à faire, et cet article l'explique complètement.
Les exceptions ne "surviennent pas" de temps en temps. Ils se produisent toujours pour des raisons valables, dont certaines sont déjà répertoriées dans les autres réponses.
Cependant, pour atténuer les problèmes avec ViewState, envisagez de le désactiver complètement. En tant que développeurs ASP.NET, nous avons souvent tendance à utiliser ViewState dans toutes sortes d'endroits où il n'est pas nécessaire, car c'est la valeur par défaut. Je pense généralement à utiliser du HTML statique avant d'envisager d'utiliser un contrôle. Si vous décidez d'utiliser un contrôle, pensez s'il a vraiment besoin que ViewState soit activé. La désactiver conduit souvent à de meilleurs temps de chargement des pages, donc si vous le pouvez, faites-le.
J'aimerais qu'il soit désactivé par défaut, donc les gens ont été forcés de penser de cette façon, mais ce n'est pas le cas.
Mettre à jour pour répondre au commentaire:
Du haut de ma tête, je trouve 3 opportunités pour désactiver ViewState.
Désactivez ViewState si les données sont chargées à chaque publication. Ce sera souvent le cas si vous construisez AJAX sites activés (c'est réel AJAX pas ce genre UpdatePanel;)), où vous chargez généralement des données lors du premier chargement, puis rechargez/mettez à jour les données en utilisant AJAX requêtes. Dans certains cas, vous pouvez même charger des données sur chaque visitez dans le seul but de désactiver ViewState, puis mettez en cache les données sur le serveur à la place.
Vous pouvez également envisager de désactiver ViewState si vous effectuez une liaison de données vers un contenu qui est vraiment statique. Parfois, je trouve une liste qui est liée à une petite table de données statiques dans la base de données ou quelque chose comme ça. Maintenant, cela peut être dangereux, mais si je suis convaincu que les données ne changeront pas, je pourrais déplacer les données dans la page en tant que contenu statique (vous pouvez les envelopper dans un contrôle séparé afin de ne pas avoir plusieurs copies statiques des données ). Mais si les données changent, vous devrez les modifier manuellement.
Des contrôles simples tels que les étiquettes sont souvent de bons candidats pour désactiver ViewState.
Enfin, vous pouvez passer au framework ASP.NET MVC et dire au revoir à ces problèmes pour toujours, c'est ce que je prévois de faire même si je vais rencontrer d'autres problèmes. ;)
BlowDart a la bonne réponse pour le problème de Viewstate non valide. C'est probablement votre pool d'applications qui est recyclé et change la clé de chiffrement.
Voir ces messages pour le support:
Problème erratique de Viewstate invalide dans une application .NET
Rendre la connexion utilisateur persistante avec ASP .Net Membership
l'état d'affichage invalide n'a aucune valeur pour votre enregistreur ou pour les utilisateurs ou pour votre site Web, les utilisateurs finaux ne voient jamais ces erreurs. pour éviter cette erreur, essayez d'ajouter ce qui suit dans Global.ascx :
void Application_Error(object sender, EventArgs e)
{
if (ex is HttpException && ex.InnerException is ViewStateException)
{
Response.Redirect(Request.Url.AbsoluteUri);
return;
}
}
pour plus d'informations, consultez le lien suivant:
https://www.karpach.com/viewstateexception-invalid-viewstate.htm
J'ai eu ce genre d'exception dans mes journaux et j'ai eu une cause très différente des autres énumérées ici. J'avais un très grand ViewState, ce qui fait partie du problème. Mais cela se combinait avec un autre problème pour provoquer ces exceptions (et peut-être de mauvaises réponses occasionnelles d'IIS).
La base de code sur laquelle je travaille a un code sophistiqué pour éviter les doubles clics, et dans le cadre de cela, il ajoute des éléments au javascript de chaque événement de clic de bouton qui désactive le bouton après le premier clic, puis effectue la publication habituelle. Mais appeler la publication comme ça était un problème car certains de mes boutons avaient déjà un appel de publication généré automatiquement par .NET. Je me retrouvais donc avec des doubles publications, dont l'une avait un ViewState invalide. La suppression de la publication supplémentaire a mis fin aux exceptions pour moi.
Je sais que je devrais vraiment réduire considérablement la taille du ViewState, mais il s'agit d'une grande base de code héritée et un changement comme celui-ci serait très invasif.
Il n'y a pas grand-chose que vous puissiez faire à propos de la première - je piège de telles exceptions et renvoie l'utilisateur à une page d'erreur avec un message du type "La page sur laquelle vous étiez a expiré. Cela se produit normalement lorsque vous essayez de revisiter une page où vous avait déjà saisi des données. "
Je vois ce dernier plus sur des pages assez grandes qui utilisent UpdatePanels. Je pense que c'est lorsque l'utilisateur publie (ou rappelle éventuellement) avant que le chargement de la page ne soit terminé, donc tout le javascript qui n'est pas marqué à la fin de la page ne s'est pas encore exécuté.
Encore une fois, vous ne pouvez pas faire grand-chose à leur sujet, sauf afficher un message convenablement convivial sur votre page d'erreur.
Ce n'est probablement pas une bonne idée d'ignorer cette erreur. En plus de toutes les réponses ci-dessus, vous voudrez peut-être examiner la taille de votre état de vue. Un grand état de vue peut être tronqué par un serveur proxy.
Si votre état d'affichage est grand, il peut être judicieux d'utiliser une trace ASP.net pour voir quels contrôles utilisent viewstate et où vous pouvez le désactiver.
Selon Wayne Walter Berry dans this blog, un autre coupable peut utiliser le doctype XHTML dans IE8 sans avoir de balisage conforme XHTML sur la page. Cela peut entraîner IE8 pour envoyer des paramètres brouillés à scriptresource.axd et lever l'exception viewstate non valide.
Il recommande de s'assurer que tous les blocs javascript sont enveloppés avec // <![CDATA[]]> ou simplement changer le doctype (ce qui pourrait causer d'autres problèmes de CSS/style sur votre page).