asp.net error-handling viewstate

asp.net - ¿Debo ignorar el error de estado de vista Inválido ocasional?



error-handling viewstate (10)

Bueno, eso depende. El estado de visualización no válido puede suceder por una variedad de razones.

  1. Viewstate es demasiado grande y no ha terminado de renderizarse antes de que un usuario genere una devolución de datos en la página. La solución generalmente es deshabilitar todos los controles que desencadenan devoluciones y habilitarlos para el lado del cliente una vez que la página ha terminado de cargarse, consulte http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate- mac-failed-error.aspx
  2. Está utilizando MAC de viewstate (y debe serlo, por razones de seguridad) pero no ha establecido una clave de máquina y el grupo de aplicaciones se ha reciclado generando una nueva. No olvides configurar un ViewStateUserKey.
  3. Alguien está usando una versión anterior de IE en el mac donde trunca los campos de formulario ocultos. En este caso, deberá mover viewstate fuera de la página al estado de la sesión .
  4. Los problemas de Viewstate MAC generalmente indican que está en una granja de servidores web y olvidó configurar una clave de máquina en web.config. Sin embargo, si has hecho esto, entonces es probable que alguien esté tratando de hacer cosas malas (bots publicando comentarios, alguien intentando activar eventos para controles desactivados, etc.). La causa de estos debe rastrearse solo para descartar posibles problemas de seguridad.

Hagas lo que hagas no desactives la validación viewstate o evento.

De vez en cuando (una vez al día más o menos) estamos viendo los siguientes tipos de errores en nuestros registros para una aplicación ASP.NET 3.5

  • Estado de visualización no válido
  • No válido postback o argumento de devolución de llamada

¿Son algo que "simplemente sucede" de vez en cuando con una aplicación ASP.NET? ¿Alguien recomendaría pasar mucho tiempo tratando de diagnosticar qué está causando los problemas?

Las excepciones no "simplemente suceden" de vez en cuando. Siempre ocurren por razones válidas, algunas de las cuales ya están enumeradas en las otras respuestas.

Sin embargo, para aliviar los problemas con ViewState, considere desactivarlo por completo. Como desarrolladores de ASP.NET, solemos utilizar ViewState en todo tipo de lugares donde no es necesario porque es el predeterminado. Normalmente pienso en usar static html antes de considerar usar un control. Si decide usar un control, piense si realmente necesita que ViewState esté habilitado. Deshabilitarlo a menudo conduce a mejores tiempos de carga de la página, por lo que si puedes, hazlo.

Desearía que estuviera deshabilitado por defecto, así que las personas se vieron obligadas a pensar de esta manera, pero no es así.

Actualiza para responder el comentario:

Tengo tres oportunidades para desactivar ViewState.

  1. Deshabilita ViewState si los datos se cargan en cada devolución. Este será a menudo el caso si está creando sitios habilitados para AJAX (ese es AJAX real, no ese tipo de UpdatePanel;)), donde generalmente carga datos en la primera carga y luego recarga / actualiza datos usando solicitudes AJAX. En algunos casos, incluso podría cargar datos en cada visita con el único propósito de deshabilitar ViewState, y luego almacenar en caché los datos en el servidor.

  2. También puede considerar deshabilitar ViewState si se enlaza con contenido que es realmente estático. A veces encuentro una lista que está unida a datos a una pequeña tabla de datos base estáticos en la base de datos o algo así. Ahora, esto puede ser peligroso, pero si estoy convencido de que los datos no cambiarán, podría mover los datos a la página como contenido estático (podría envolverlo en un control separado para que no tenga varias copias estáticas de los datos). ) Pero si los datos cambian entonces, tendrá que cambiarlos manualmente.

  3. Controles simples como Etiquetas son a menudo buenos candidatos para deshabilitar ViewState.

Finalmente, podría cambiar al marco ASP.NET MVC y despedirse de estos problemas para siempre, eso es lo que planeo hacer aunque tenga que enfrentar otros problemas. ;)

No hay mucho que pueda hacer con respecto al primero: atrapo esas excepciones y le devuelvo al usuario una página de error con un mensaje como "La página en la que estaba ha expirado. Esto normalmente sucede cuando intenta volver a visitar una página donde ya había ingresado datos ".

Veo esto último en páginas bastante grandes que usan UpdatePanels. Creo que es cuando el usuario publica (o posiblemente vuelve a llamar) antes de que la página haya terminado de cargarse, por lo que no se han ejecutado todos los javascript que se etiquetan al final de la página.

Nuevamente, no hay mucho que pueda hacer sobre ellos, excepto mostrar un mensaje amigable en su página de error.

Un problema puede estar relacionado con los enrutadores de usuarios que truncan campos de formulario. La forma de solucionar esto es establecer MaxPageStateFieldLength en un número pequeño (como 100) en web.config y ViewState se divide en pequeños fragmentos. Es muy simple de hacer, y este artículo lo explica completamente.

Probablemente no sea una buena idea ignorar este error. Además de todas las respuestas anteriores, es posible que desee considerar el tamaño de su viewstate. Un servidor proxy puede truncar un gran viewstate.

Si su estado de vista es grande, puede ser una buena idea usar un rastreo de ASP.net para ver qué controles están usando viewstate y dónde puede desactivarlo.

De acuerdo con Wayne Walter Berry en esta publicación de blog, otro culpable puede ser usar el doctype XHTML en IE8 sin tener marcado XHTML en la página. Esto puede hacer que IE8 envíe parámetros codificados a scriptresource.axd y arroje la excepción invalid viewstate.

Él recomienda asegurarse de que todos los bloques de javascript están envueltos con // <![CDATA[]]> o simplemente cambiando el tipo de documento (lo que podría causar otros problemas de css / styling en su página).

Tuve este tipo de excepción lanzada en mis registros y tuve una causa muy diferente a las otras enumeradas aquí. Tuve un ViewState muy grande, que es parte del problema. Pero eso se combinaba con otro problema para causar estas excepciones (y posiblemente malas respuestas ocasionales de IIS).

La base de código en la que estoy trabajando tiene un código elegante para evitar clics dobles y, como parte de eso, agrega algunas cosas al javascript de cada clic del evento que desactiva el botón después del primer clic y luego realiza la devolución de datos habitual. Pero llamar a la devolución de datos de ese modo fue un problema porque algunos de mis botones ya tenían una devolución de llamada generada por .NET automáticamente. Así que estaba terminando con doble devoluciones, una de las cuales tenía un ViewState inválido. La eliminación de la devolución de datos adicional detuvo las excepciones para mí.

Sé que realmente debería estar disminuyendo drásticamente el tamaño del ViewState, pero esta es una gran base de código heredado y un cambio como ese sería muy invasivo.

el estado de vista no válida no tiene ningún valor para su registrador o para los usuarios o para su sitio web, los usuarios finales nunca ven esos errores. para evitar este error intente agregar lo siguiente en Global.ascx :

void Application_Error(object sender, EventArgs e) { if (ex is HttpException && ex.InnerException is ViewStateException) { Response.Redirect(Request.Url.AbsoluteUri); return; } }

para más información, consulte el siguiente enlace:

https://www.karpach.com/viewstateexception-invalid-viewstate.htm