Hin und wieder (einmal täglich oder so) sehen wir die folgenden Arten von Fehlern in unseren Protokollen für eine ASP.NET 3.5-AnwendungSollte ich den gelegentlichen ungültigen Viewstate-Fehler ignorieren?
Sind diese Dinge von Zeit zu Zeit mit einer ASP.NET-Anwendung "passiert"? Würde jemand empfehlen, dass wir viel Zeit damit verbringen, zu diagnostizieren, was die Probleme verursacht?
Nun, es kommt darauf an. Ein ungültiger Viewstate kann aus verschiedenen Gründen auftreten.
Was immer Sie tun nicht Ansichtszustand oder Ereignisvalidierung deaktivieren.
Es gibt nicht viel, was Sie tun können - ich fange solche Ausnahmen ein und blicke den Benutzer auf eine Fehlerseite mit einer Nachricht wie folgt: "Die Seite, auf der Sie waren, ist abgelaufen. Dies passiert normalerweise, wenn Sie versuchen, erneut zu besuchen eine Seite, auf der Sie bereits Daten eingegeben haben. "
Ich sehe letztere auf einer ziemlich großen Seiten, die UpdatePanels verwenden. Ich denke, es ist, wenn der Benutzer zurücksetzt (oder möglicherweise zurückruft), bevor die Seite fertig geladen ist, so dass nicht alle Javascript, die am Ende der Seite getaggt wird, noch nicht gelaufen sind.
Auch hier können Sie nicht viel tun, außer dass Sie auf Ihrer Fehlerseite eine entsprechend freundliche Nachricht anzeigen.
Ein Problem kann mit Benutzerroutern zu tun haben, die Formularfelder abschneiden. Um dies zu ändern, setzen Sie MaxPageStateFieldLength auf eine kleinere Zahl (z. B. 100) in web.config und der ViewState wird in kleine Blöcke aufgeteilt. Es ist sehr einfach zu tun, und this article erklärt es vollständig.
hilft mir diese Änderung, "Base64" -Fehler zu vermeiden? –
funktioniert nicht für mich! –
Ausnahmen "passieren" nicht von Zeit zu Zeit. Sie kommen immer aus berechtigten Gründen vor, von denen einige bereits in den anderen Antworten aufgeführt sind.
Um Probleme mit ViewState zu beheben, sollten Sie es jedoch insgesamt deaktivieren. Als ASP.NET-Entwickler neigen wir oft dazu, ViewState überall dort zu verwenden, wo es nicht benötigt wird, weil es der Standard ist.Normalerweise denke ich über die Verwendung von statischem HTML nach, bevor ich ein Steuerelement in Betracht ziehe. Wenn Sie sich dafür entscheiden, ein Steuerelement zu verwenden, überlegen Sie, ob ViewState tatsächlich aktiviert werden muss. Die Deaktivierung führt oft zu besseren Seitenladezeiten. Wenn Sie können, sollten Sie es tun.
Ich wünschte, es wäre standardmäßig deaktiviert, so dass die Menschen gezwungen waren, auf diese Weise zu denken, aber es ist nicht.
aktualisieren Kommentar zu beantworten:
Von der Spitze von meinem Kopf, den ich mit 3 Möglichkeiten kommen Viewstate auszuschalten.
Deaktivieren Sie ViewState, wenn Daten auf jedem Postback geladen werden. Dies ist häufig der Fall, wenn Sie AJAX-fähige Sites erstellen (das ist real AJAX nicht diese UpdatePanel Art;)), wo Sie normalerweise Daten beim ersten Laden laden und dann Daten mit AJAX-Anforderungen neu laden/aktualisieren. In einigen Fällen können Sie sogar Daten bei jedem Besuch laden, um ViewState zu deaktivieren und stattdessen die Daten auf dem Server zwischenzuspeichern.
Sie können ViewState auch deaktivieren, wenn Sie auf Inhalte zugreifen, die wirklich statisch sind. Manchmal finde ich eine Liste, die mit einer kleinen statischen Basistabelle in der Datenbank verbunden ist oder so ähnlich. Nun kann dies gefährlich sein, aber wenn ich davon überzeugt bin, dass die Daten werden nicht ändern könnte ich die Daten in die Seite als statische Inhalte bewegen (Sie können es in einem separaten Steuer wickeln konnte, so dass Sie nicht mehrere statische Kopien der Daten haben). Wenn sich die Daten dann ändern, müssen Sie sie manuell ändern.
Einfache Steuerelemente wie Labels sind oft gute Kandidaten zum Deaktivieren von ViewState.
Schließlich könnten Sie zu ASP.NET MVC-Framework wechseln und auf Wiedersehen für immer auf diese Probleme Welle, das ist, was ich plane zu tun, auch wenn ich einige andere Probleme konfrontiert sein wird. ;)
Es ist wahrscheinlich keine gute Idee, diesen Fehler zu ignorieren. Zusätzlich zu all den oben genannten Antworten sollten Sie überlegen, wie groß Ihr Viewstatus ist. Ein großer Viewstate kann von einem Proxy-Server abgeschnitten werden.
Wenn Ihr Ansichtszustand groß ist, kann es eine gute Idee sein, eine ASP.net-Ablaufverfolgung zu verwenden, um zu sehen, welche Steuerelemente viewstate verwenden und wo Sie diese deaktivieren können.
Was würden Sie als einen großen (oder zu großen) Viewstate betrachten? –
BlowDart hat die richtige Antwort für das Problem "Invalid Viewstate". Wahrscheinlich wird Ihr App-Pool wiederverwendet und der Verschlüsselungsschlüssel geändert.
Sehen Sie diese Beiträge für die Unterstützung:
Laut Wayne Walter Berry in this Blog einen weiteren Täter veröffentlichen kann, ohne dass XHTML-konformen Markup auf dem mit dem XHTML-Doctype in IE8 sein Seite. Dies kann dazu führen, dass IE8 verschlüsselte Parameter an scriptresource.axd sendet und die ungültige viewstate-Ausnahme auslöst.
Er empfiehlt, sicherzustellen, dass alle JavaScript-Blöcke mit // <![CDATA[]]> verpackt sind oder einfach den Doctype ändern (was andere CSS-/Styling-Probleme auf Ihrer Seite verursachen könnte).
Update: Microsoft kündigte an, dass die folgenden Bug-Fix für IE 8 behebt dieses Problem:
http://blogs.msdn.com/ieinternals/archive/2010/04/01/IE8-Lookahead-Downloader-Fixed.aspx
ich diese Art von Ausnahme in meinem Logs geworfen hatte und hatte eine ganz andere Ursache von den anderen hier aufgeführt. Ich hatte einen sehr großen ViewState, der Teil des Problems ist. Aber das hat mit einem anderen Problem kombiniert, um diese Ausnahmen (und möglicherweise gelegentliche schlechte Antworten von IIS) zu verursachen.
Die Codebasis, an der ich arbeite, hat einen ausgefallenen Code, um Doppelklicks zu vermeiden, und als Teil davon fügt sie dem JavaScript jedes Klickereigniss, das die Schaltfläche nach dem ersten Klick deaktiviert, etwas hinzu das übliche Postback. Aber das Aufrufen des Postbacks war ein Problem, da einige meiner Buttons bereits einen Postback-Aufruf hatten, der automatisch von .NET generiert wurde. So endete ich mit doppelten Postbacks, von denen einer einen ungültigen ViewState hatte. Das Entfernen des zusätzlichen Postbacks stoppte die Ausnahmen für mich.
Ich weiß, ich sollte wirklich die Größe des ViewState drastisch verringern, aber dies ist eine große Legacy-Code-Basis und eine Änderung wie das wäre sehr invasiv.
ungültiger Ansichtszustand hat keinen Wert für Ihren Logger oder für Benutzer oder für Ihre Website, Endbenutzer sehen diese Fehler nie. diesen Fehler zu vermeiden versuchen die folgenden In Global.ascx hinzuzufügen:
void Application_Error(object sender, EventArgs e)
{
if (ex is HttpException && ex.InnerException is ViewStateException)
{
Response.Redirect(Request.Url.AbsoluteUri);
return;
}
}
für weitere Informationen überprüfen unter folgendem Link: 2
https://www.karpach.com/viewstateexception-invalid-viewstate.htm
Können Sie mehr Details über Artikel? –
Gut Viewstate enthält eine Signatur, um zu verhindern, dass jemand es auf der Clientseite bearbeitet. Diese Signatur wird vom Maschinenschlüssel für den Server generiert. Wenn Sie nicht speziell einen Maschinenschlüssel festlegen, wird dieser beim Neustart des Anwendungspools neu generiert, wodurch alle vorherigen Anzeigestatus ungültig werden. Wenn Sie über eine Benutzerauthentifizierung verfügen, sollten Sie auch einen ViewStateUserKey zum Schutz vor CSRF einrichten. – blowdart