asp.net problème de session: variable après la redirection

Question

Juste "utilisé à nouveau session" comme d'habitude ... mais fait face à une situation étrange. .net 3.5

1. Objet inséré dans la variable de session.
2. Juste dans la ligne suivante - récupéré avec succès.
3. Redirigé, retrieving - variable est la valeur par défaut, mais le constructeur d'objet n'a pas été appelé.

Je ne vais pas décrire comment je passe quelques heures sur le débogage toute opération qui pourrait réinitialiser la variable ... car après ces heures je viens de changer le mode StateServer à InProc ... et VIE CAME)

Pourquoi? J'avais l'habitude de voir une exception si j'essayais d'insérer quelque chose non sérialisable etc. dans le serveur d'état - mais je suis inséré et récupéré ... Aussi dans la trace j'ai vu un objet du même type en session, mais avec un autre id. Et enfin - J'utilise du vieux code testé (en cas de redirection et de stockage de session ou de récupération) MAIS avec un nouveau type d'objet.

Qu'est-ce qui se passe)

ÉDITÉ:

Vérifié dans le trafic pare-feu sur le port-serveur d'état - asp n'envoie pas là quoi que ce soit au cours du traitement de la demande de page. C'est pourquoi je peux récupérer la variable suivante. Mais pourquoi écrit-il l'objet par défaut dans le serveur d'état plus tard?

Answer 1

Dans la classe inférieure de la hiérarchie d'objets sérialisés était fondée la classe qui n'était pas marquée comme sérialisable. Il semble que asp ne puisse pas lancer une telle exception si un objet non sérialisable est imbriqué dans des sous-classes. Tellement stupide (

Answer 2

Une réponse.Redirect peut provoquer ce comportement; Une fois que la redirection est appelée, une exception d'abandon de thread est levée, ce qui peut empêcher la définition de la variable de session.

Ce problème peut être surmonté avec la surcharge

Response.Redirect("~/default.aspx", false); 

Cet appel ne pas interrompre le fil et donc la variable de session sera réglée avec succès.

Answer 3

Quel est l'environnement de votre machine dev? Votre section de modèle de processus de votre pool d'applications, combien de processus de travail utilisez-vous?

Si vous utilisez l'état de session inProc mais que votre modèle de processus de pool d'applications utilise plus de 1 processus de travail, vous rencontrerez ce type de problème. Gardez à l'esprit que les paramètres de votre pool d'applications sur votre machine dev seront probablement différents de ceux de votre machine de production. Ainsi, le changement entre l'état de session inproc et le service d'état de session a une implication énorme.