Ogni tanto (una volta al giorno o giù di lì) che stiamo vedendo i seguenti tipi di errori nei nostri registri per un 3.5 un'applicazione ASP.NETDevo ignorare l'errore occasionale del viewstate non valido?
Sono questi qualcosa che "accade solo" di volta in volta con un'applicazione ASP.NET? Qualcuno ci consiglierebbe di dedicare molto tempo a cercare di diagnosticare cosa sta causando i problemi?
Beh, dipende. Il viewstate non valido può verificarsi per una serie di motivi.
Qualunque cosa tu faccia non fanno spegnere ViewState o di un evento di convalida.
Non c'è molto che si possa fare per il primo: io intrappoli tali eccezioni e rimbalzo l'utente in una pagina di errore con un messaggio sulla falsariga di "La pagina in cui ti trovavi è scaduta. Normalmente succede quando provi a rivisitare una pagina in cui hai già inserito i dati. "
Vedo quest'ultimo più su pagine piuttosto grandi che utilizzano UpdatePanel. Penso che sia quando l'utente postback (o possibilmente richiama) prima che la pagina abbia finito di caricare, quindi non tutto il javascript che viene taggato alla fine della pagina è ancora in esecuzione.
Ancora una volta, non c'è molto che puoi fare su di loro se non mostrare un messaggio adeguatamente amichevole sulla tua pagina di errore.
Un problema può avere a che fare con i router degli utenti che tronchiano i campi modulo. Il modo per aggirare questo è impostare MaxPageStateFieldLength su un numero ridotto (come 100) in web.config e ViewState viene suddiviso in piccoli blocchi. È molto semplice da fare, e this article lo spiega completamente.
questa modifica mi aiuta ad evitare errori "Base64"? –
non funziona per me! –
Le eccezioni non "si verificano" di volta in volta. Si verificano sempre per motivi validi, alcuni dei quali sono già elencati nelle altre risposte.
Tuttavia, per alleviare i problemi con ViewState prendere in considerazione la disabilitazione del tutto. Come sviluppatori ASP.NET, spesso tendiamo a utilizzare ViewState in tutti i tipi di posizioni in cui non è necessario perché è l'impostazione predefinita.Di solito penso di usare l'html statico prima di prendere in considerazione l'utilizzo di un controllo. Se decidi di utilizzare un controllo, pensa se è necessario che ViewState sia abilitato. Disabilitarlo porta spesso a tempi di caricamento delle pagine migliori, quindi se puoi, fallo.
Vorrei che fosse disabilitato di default così le persone sono state costrette a pensare in questo modo, ma non lo è.
Update per rispondere a un commento:
della parte superiore della mia testa io vengo con 3 possibilità di spegnere ViewState.
Disabilitare ViewState se i dati vengono caricati su ogni postback. Questo sarà spesso il caso se stai costruendo siti abilitati AJAX (ovvero reale AJAX non quel tipo UpdatePanel;)), dove di solito carichi i dati sul primo carico e poi ricarichi/aggiorni i dati usando le richieste AJAX. In alcuni casi è possibile caricare i dati su ogni visita al solo scopo di disabilitare ViewState e quindi memorizzare i dati sul server.
Si può anche considerare di disabilitare ViewState se si associa al contenuto statico. A volte trovo una lista che è data da una piccola tabella statica basata sul database o qualcosa del genere. Ora, questo può essere pericoloso, ma se sono convinto che i dati non cambieranno, potrei spostare i dati nella pagina come contenuto statico (potresti avvolgerlo in un controllo separato in modo da non avere più copie statiche dei dati). Ma se i dati poi cambiano, dovrai cambiarli manualmente.
Controlli semplici come Etichette sono spesso buoni candidati per disabilitare ViewState.
Infine si potrebbe passare a framework ASP.NET MVC e dire addio per sempre a questi problemi, che è quello che ho intenzione di fare anche se dovrò affrontare alcuni altri problemi. ;)
Probabilmente non è una buona idea ignorare questo errore. Oltre a tutte le risposte di cui sopra, potresti voler considerare l'ampiezza del tuo stato di visualizzazione. Un ampio viewstate può essere troncato da un server proxy.
Se lo stato della visualizzazione è elevato, potrebbe essere una buona idea utilizzare una traccia ASP.net per vedere quali controlli stanno utilizzando viewstate e dove è possibile disattivarlo.
Che cosa considereresti un grande (o troppo grande) stato di visualizzazione? –
BlowDart ha la risposta giusta per il problema di Viewstate non valido. Probabilmente il tuo pool di app viene riciclato e cambia la chiave di crittografia.
vedere questi messaggi per il supporto:
Secondo Wayne Walter Berry in this blog inviare un altro colpevole può essere utilizzando il doctype XHTML in IE8 senza markup XHTML compliant sul pagina. Ciò può causare che IE8 invii i parametri codificati a scriptresource.axd e genera l'eccezione viewstate non valida.
Si consiglia di verificare che tutti i blocchi javascript siano avvolti con // <![CDATA[]]> o semplicemente cambiando il doctype (che potrebbe causare altri problemi css/styling sulla pagina).
Aggiornamento: Microsoft ha annunciato che la seguente correzione di bug per IE 8 risolve questo problema:
http://blogs.msdn.com/ieinternals/archive/2010/04/01/IE8-Lookahead-Downloader-Fixed.aspx
ho avuto questo tipo di eccezioni essere gettati nei miei ceppi e aveva una causa molto diverso dagli altri elencati qui. Ho avuto un ViewState molto grande, che è parte del problema. Ma questo è stato combinato con un altro problema per causare queste eccezioni (e, eventualmente, cattive risposte occasionali da IIS).
Il codice di base su cui sto lavorando ha un codice di fantasia per evitare il doppio clic e, come parte di ciò, aggiunge alcune informazioni alla javascript di ogni clic del pulsante che disattiva il pulsante dopo il primo clic, quindi il solito postback. Ma chiamare questo postback è stato un problema perché alcuni dei miei pulsanti avevano già una chiamata postback generata automaticamente da .NET. Quindi stavo finendo con i double postback, uno dei quali aveva un ViewState non valido. La rimozione del postback aggiuntivo ha bloccato le eccezioni per me.
So che dovrei davvero ridurre drasticamente le dimensioni del ViewState, ma questa è una grande base di codice legacy e un cambiamento del genere sarebbe molto invasivo.
lo stato di visualizzazione non valido non ha alcun valore per il tuo registratore o per gli utenti o per il tuo sito web, gli utenti finali non vedono mai quegli errori. per evitare questo errore tenta di aggiungere il seguente In Global.ascx:
void Application_Error(object sender, EventArgs e)
{
if (ex is HttpException && ex.InnerException is ViewStateException)
{
Response.Redirect(Request.Url.AbsoluteUri);
return;
}
}
per ulteriori informazioni controllare il seguente link:
https://www.karpach.com/viewstateexception-invalid-viewstate.htm
Puoi dare maggiori dettagli su punto 2? –
Well viewstate contiene una firma per proteggersi da qualcuno che lo modifica sul lato client. Quella firma è generata dalla chiave della macchina per il server. A meno che non si imposti un codice macchina specifico, esso viene rigenerato al riavvio del pool di applicazioni, rendendo tutti i precedenti viewstate non validi. Se si dispone dell'autenticazione utente, è necessario impostare anche ViewStateUserKey per proteggersi da CSRF. – blowdart