FAQ ASP.NET/VB.NET

					Dim MonObjet As Object
					Dim IDvariable As String = "ID"
					HttpContext.Current.Session.Add(IDvariable,MonObjet)
				

ou

					Session(IDVariable) = monObjet
				

qui effectue la même opération mais de manière implicite.

On peut ajouter n'importe quel objet en variable de session et retrouver cet objet par la suite en fonction de son ID.

Quand on ajoute une variable de session celle-ci est unique pour chaque utilisateur.

On veillera à ne pas stocker de trop gros objets en variable de session car pour chaque utilisateur le serveur web stockera cet objet en mémoire tant que la session est active.

L'utilisation abuse des variables de session peut donc poser des problèmes de consommation de mémoire vive sur le serveur web avec une forte montée en charge.

					dim MonObjet as Object
					dim IDvariable as String = "ID"
					MonObjet = HttpContext.Current.Session(IDvariable)
				

Si il n'existe pas de variable appelée "ID", MonObjet vaudra Nothing. Il est donc préférable de vérifier que MonObjet ne vaut pas Nothing avant d'effectuer certaines opérations dessus tels que des castings, des substring, ...

L'exemple typique est le suivant :

					 
Session["IsLogged"] = True
Response.Redirect("~/page.aspx")

				

Cependant, la variable de session n'est pas enregistrée pour la simple raison qu'un Response.Redirect tel qu'indiqué arrête d'envoyer la réponse (une exception ThreadAbortException est lancée). Dès lors le cookie temporaire contenant le SessionID n'existe pas vu qu'il est censé être envoyé lors de cette réponse.
Pour éviter cela, utilisez la méthode prévue à cet effet, à savoir FormsAuthentication.RedirectFromLogingPage qui évite de stopper l'exécution de manière brutale. De plus, cette méthode permet de renvoyer la page qui avait été initialement demandée, ce qui permet par exemple de permettre d'enregistrer une adresse dans ses favoris.

Tout d'abord, si cela arrive lors du login, je vous conseille de lire Après le login, j'enregistre des éléments en session et celles-ci sont perdues. Pourquoi et comment éviter cela ?
Ensuite, voici quelques pistes, en vrac :

• Le pool d'applications est configuré pour être recyclé plus régulièrement que ce que vous ne l'espériez
• Votre nom de serveur comporte un underscore (ceci interfère sur la création du fameux cookie volatile contenant le sessionID)
• Le processus aspnet_wp.exe (ou w3wp.exe sous Windows 2003) s'arrête (notez qu'il s'arrête automatiquement toutes les 29h par défaut ou après 20 minutes d'inactivité)
• L'antivirus empêche la création du cookie temporaire
• Un répertoire est supprimé au sein de l'application

Normal ? Disons que c'est compréhensible lorsque l'on lit ceci :
Pour résumer, sous Internet Explorer, seulement 20 cookies sont autorisés par domaine.