Digamos que tiene una página aspx que no depende de la sesión, pero confía en viewstate para persistencia entre las devoluciones.¿ViewState expira?
Si un usuario está accediendo a esta página y se va para un largo almuerzo, ¿viewstate seguirá siendo válido cuando regrese?
No ViewState se guarda como parte del proceso PostBack. Sin embargo, puede override SavePageStateToPersistenceMedium() de la clase de página y LoadPageStateFromPersistenceMedium(), para implementar ese comportamiento si lo desea. Para obtener más información, lea Understanding the ASP.NET ViewState.
Tenga en cuenta que Página ViewState se almacena en la Sesión de modo que si su sesión expira, el ViewState se perderá. No diría que esto es ViewState que expira, pero sí, se destruirá después del tiempo de espera de la sesión.
Viewstate en sí no caduca. Dado que se publicó en un formulario, se puede reconstituir en cualquier momento.
According to MSDN .. ".. es posible que el estado de visualización caduque si una página no se vuelve a publicar dentro del tiempo de caducidad de la sesión". Por lo tanto, en una ronda de algún tipo, puede caducar si su sesión lo hace, pero viewstate no caduca directamente. Como no está utilizando el estado de la sesión de todos modos, no tiene que preocuparse por la caducidad implícita.
Tenga en cuenta que no habría dicho que caducó. Esa fue MS, que cité en su propio artículo titulado Controlling ViewState
Ese 'control de viewstate' es un artículo sobre cómo mover ViewState a las sesiones para obtener un mejor rendimiento en clientes básicos como teléfonos. Si lo hace y usa el estado predeterminado save-view-in-session, mantiene viewstate en sesión y solo conserva los últimos X viewstates en la sesión. Pero eso no significa que viewstate caduque, lo que significa que la sesión expira y ha movido viewstate a sesión en lugar de usar las variables de formulario. Creo que estás mezclando dos cosas diferentes aquí. –
Viewstate no caduca, siempre y cuando todavía estén en la página, seguirá allí y funcional.
Viewstate no caduca.
Todos los datos de viewstate se almacenan en el cliente y se envían nuevamente al servidor cuando el usuario ejecuta una devolución de datos.
Esto tiene algunas implicaciones muy interesantes, y se explica minuciosamente here.
ViewState se mantiene en un campo oculto en la página misma. De modo que, mientras el usuario tenga la página, tendrá el ViewState. Pero si su aplicación automáticamente cierra la sesión del usuario después de un cierto período de tiempo, seguir teniendo el ViewState puede no hacerle ningún bien.
De forma predeterminada, Viewstate se incluye con el contenido html como una entrada oculta. Eso significa que no caducará, pero que todo en viewstate debe cargarse desde el navegador del usuario. Como suele ser la parte más lenta de la conexión en un sitio público, poner muchas cosas en viewstate puede hacer que su sitio web parezca muy lento.
La respuesta corta es: no.
La respuesta más larga es: depende de la implementación del almacenamiento de ViewState. Puede proporcionar una implementación personalizada de ViewState que podría caducar después de una cantidad determinada de tiempo. Por ejemplo, puede almacenar ViewState en la base de datos o en el disco y enviar solo una referencia al valor almacenado en un campo oculto. Luego, puede usar el procesamiento por lotes para eliminar los datos obsoletos de ViewState o realizar la caducidad cuando se solicite.
El ViewState persistirá de POST a POST. En realidad, está almacenado dentro de un campo oculto en su formulario para que vuelva a enviarse a su servidor todo el tiempo.
Siempre y cuando no confíe en la sesión, no debería tener problemas para reconstruir el estado de la página. Sin embargo, es fácil probar el código de estado de su página: simplemente configure su sesión para que expire después de 60 segundos en su web.config y luego cargue su página, espere un poco más de un minuto (navegue hasta Stack Overflow y responda algunas preguntas) y luego haz clic en un botón en tu página.
Además, como resultado, ASP.NET por defecto encripta ViewState con una clave autogenerada. Esto puede anularse con el elemento MachineKey en el archivo web.congif. Aunque ViewState no caducará, puede dejar de ser válido si se utiliza una clave autogenerada diferente para descifrar ViewState, como después de un reinicio de IIS, la redistribución de una aplicación o el acceso a un servidor diferente en una granja de servidores web. Si planea almacenar ViewState durante largos períodos de tiempo, tenga cuidado con la forma en que está cifrado/descifrado.
Sí, ViewState expira en ciertas condiciones. Por ejemplo, cuando está utilizando iframe: s, o cuando está manteniendo una conexión "en vivo" con servidores con devoluciones de datos regulares. A continuación, puede investigar esta opción: <sessionPageState historySize="9"/>, que realmente codifica cuántos "resultados de devolución de datos" se almacenan en la sesión (si se utiliza SessionPageStatePerster). Cada devolución de datos almacena su ViewState hasta el final de la cola en Session ["__ VIEWSTATEQUEUE"], y borra ViewStates que son "muy antiguos". ¿Y cómo crees que SessionPageStatePerster decide qué ViewStates son demasiado antiguos ... al configurar alguna historySize-constant arbitraria en web.config ... Omg! Es demasiado conmigo para siempre a encontrar este problema ... Mi odio hacia la programación asp.net es indescriptible ahora .. grrr ...
Lo sentimos revivir este viejo hilo, pero la nueva información ya está disponible:
Sí, los ViewStates caducan. Vengo de 19 horas investigando sobre un problema de ViewStates que pierde sus valores entre las devoluciones de datos a intervalos largos. Me tomó un tiempo leer los documentos de MSDN y las respuestas de Stackoverflow diciendo que era básicamente imposible a menos que se utilizara una implementación de almacenamiento ViewState personalizada, que, ahora sé, no es cierto.
Mi problema estaba teniendo lugar en un entorno de SharePoint 2013. El servicio conocido como Distributed Cache (a.k.a. AppFabric) hace el almacenamiento en caché de ViewState y tiene un Time to Live asociado. Puede encontrar más información aquí: http://blogs.msdn.com/b/besidethepoint/archive/2013/03/27/appfabric-caching-and-sharepoint-1.aspx
La parte interesante de la información se puede encontrar en esta frase: "Para mejorar el rendimiento de la página, a partir de SharePoint 2013 SharePoint almacena en caché del lado del servidor de datos ViewState en lugar de transferir de nuevo y adelante a los clientes ".
Espero que esta información ayude a alguien tan desesperado como lo estaba hace 19 horas.
No Viewstate no caduca.Después de redireccionar a otra página, el valor del estado de vista se pierde o vence el estado de visualización. para más detalles http://www.c-sharpcorner.com/UploadFile/78d182/Asp-Net-state-management-techniques/
¿Cómo se indica el "No" como respuesta? Viewstate no caduca, son variables de forma. Las credenciales de usuario registradas pueden caducar en este escenario, pero eso es todo. –
Ni siquiera estoy seguro de si la respuesta de wprl es "No". depende de si falta una coma después de la palabra "No".De cualquier manera, me cuesta entender lo que esta respuesta intenta decir – Andy