object MonObjet;
string IDvariable = "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 abusive 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.

object MonObjet;
string IDvariable = "ID";
MonObjet = HttpContext.Current.Session[IDvariable];

S'il n'existe pas de variable appelée "ID", MonObjet vaudra null. Il est donc préférable de vérifier que MonObjet ne vaut pas null 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.

Les variables de sessions ASP.NET et ASP3 ne communiquent pas.

Cependant il est possible de récupérer les variables de sessions ASP.NET en ASP et inversement à l'aide de traitements plus ou moins complexes. MSDN a publié un "How To" sur le sujet

Tout d'abord pour être certain que la session est bien "réinitialisée", mettez un point d'arrêt pour vérifier que l'on passe bien dans le session_start. Vous pouvez également utiliser un Trace.Warning ou simplement un Debug.WriteLine afin de laisser un affichage quelque part signalant qu'on est bel et bien passé par le session_start.

Si c'est le cas, il s'agit certainement d'un firewall (zonealarm par exemple) qui empêche l'enregistrement des cookies nécessaires pour garder le sessionid.

Lors d'un retour serveur, le sessionid n'est pas passé et le serveur considère donc qu'il s'agit d'une nouvelle session.

Pour corriger le problème, vous pouvez utiliser un autre moyen de stocker les sessions ou affecter la valeur "true" à la propriété cookieless dans le web.config

<sessionState 
	mode="InProc"
	stateConnectionString="tcpip=127.0.0.1:42424"
	sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
	cookieless="true" 
	timeout="30" 
/>

Attention, ceci est une astuce. Il se peut qu'il y ait d'autres solutions.

Souvent, dans les applications ASP.NET, on stocke les informations relatives à un client dans des variables de Session. Ainsi pour vérifier qu'un utilisateur est bien connecté, on a recours à un test du type "if (Session["UserName"] != null) { ... }".
Cependant, suite à une faute de frappe, on pourrait avoir "if (Session["UserNamme"] != null) { ... }" par exemple.

Pour limiter le nombre d'erreurs possibles, il suffit de faire une classe qui "gère" les accès aux différentes variables de session.

public class SessionTransfert
{
	public class Exemple1
	{
		public static string Teacher_Name
		{
			get
			{
				if (HttpContext.Current.Session["Teacher_Name"] != null)
					return HttpContext.Current.Session["Teacher_Name"].ToString();
				else
					throw new SessionUndefinedException("Teacher_Name");
			}
			set { HttpContext.Current.Session["Teacher_Name"] = value; }
		}
		
		public static string Teacher_FirstName
		{
			get
			{
				if (HttpContext.Current.Session["Teacher_FirstName"] != null)
					return HttpContext.Current.Session["Teacher_FirstName"].ToString();
				else
					throw new SessionUndefinedException("Teacher_FirstName");
			}
			set { HttpContext.Current.Session["Teacher_FirstName"] = value; }
		}
	}

	public class NewSchool
	{
		public static int School_Id
		{
			get
			{
				if (HttpContext.Current.Session["School_Id"] != null)
					return Convert.ToInt32(HttpContext.Current.Session["School_Id"]);
				else
					throw new SessionUndefinedException("School_Id");
			}
			set { HttpContext.Current.Session["School_Id"] = value; }
		}
	}
	// ...
}

Une autre solution serait d'utiliser des constantes ...