Question : Pourquoi la Session est-elle parfois perdue sur certaines machines ?
Réponse : Cela peut être lié à l'environnement de la machine, tel qu'un pare-feu ou un logiciel antivirus. Essayez de désactiver le pare-feu.
Q : Pourquoi la méthode Session_End n'est-elle pas déclenchée lorsque Session.Abandon est appelée ?
Réponse : Tout d’abord, la méthode Session_End ne prend en charge que les sessions de type InProc (en cours). Deuxièmement, pour activer la méthode Session_End, la Session doit exister (c'est-à-dire que la Session a été utilisée dans le système) et au moins une requête doit être complétée (cette méthode sera appelée dans cette requête).
Q : Pourquoi ma session est-elle souvent perdue lorsque je l'utilise en mode InProc ?
Réponse : Ce problème est généralement dû au recyclage de l'application, car lors de l'utilisation de la session en cours, la session est enregistrée dans le processus aspnet_wp. Lorsque le processus est recyclé, la session disparaîtra naturellement. été recyclé, vous pouvez utiliser Vérifiez l'Observateur d'événements de votre système pour plus d'informations.
Pour des informations spécifiques, veuillez vous référer à :
Les variables de session sont perdues par intermittence dans les applications ASP.NET
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q316148
Il y avait également un bug dans la version 1.0 qui entraînait le recyclage et le redémarrage du processus de travail. Ce bug a été corrigé dans la version 1.1 et sp2.
Pour des informations détaillées sur ce bug, veuillez vous référer à :
Le processus de travail ASP.NET (Aspnet_wp.exe) est recyclé de manière inattendue.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q321792
Question : Pourquoi l'ID de la nouvelle session est-il le même que celui d'origine une fois la session expirée ou abandonnée ?
Réponse : Étant donné que l'ID de session est enregistré dans l'instance du navigateur client, lorsque la session expire et que la session est rétablie sur le serveur, l'ID de session transmis par le navigateur sera utilisé. Par conséquent, après l'expiration de la session, l'ID de session ne changera pas après son rétablissement.
Q : Pourquoi le SessionID est-il différent pour chaque demande ?
Réponse : Ce problème peut être dû au fait qu'aucune information n'est enregistrée dans la session, c'est-à-dire que la session n'est utilisée nulle part dans le programme. Une fois les informations enregistrées dans la session, le SessionID sera toujours lié au navigateur et le SessionID ne changera pas pour le moment.
Q : La session peut-elle être partagée entre ASP et ASP.NET ?
Réponse : Oui. Mais il s'agit d'un processus relativement compliqué. Microsoft propose une solution officielle. Veuillez vous référer à : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/ConvertToASPNET .aspQ.
: Quels types d'objets peuvent être enregistrés dans Session ?
Réponse : Cela dépend du mode Session utilisé. Lors de l'utilisation d'une session en cours (InProc), n'importe quel objet peut être facilement enregistré. Si vous utilisez un mode non-InProc, vous ne pouvez enregistrer que les objets pouvant être sérialisés et désérialisés. Si l'objet enregistré à ce moment ne prend pas en charge la sérialisation, il ne peut pas être enregistré dans la session de ce mode (non-InProc).
Q : Pourquoi ne puis-je pas utiliser les méthodes Response.Redirect et Server.Transfer dans Session_End pour accéder à une page ?
Réponse : Session_End est une fonction de traitement d'événements déclenchée à l'intérieur du serveur. Il est basé sur un minuteur à l'intérieur du serveur. Lorsque l'événement est déclenché, il n'y a aucun objet HttpRequest pertinent sur le serveur, donc les méthodes Response.Redirect et Server.Transfer ne peuvent pas être utilisées pour le moment.
Q : Puis-je obtenir l'objet HttpContext dans Session_End ?
Réponse : Non, car cet événement n'est associé à aucune requête (Request) et n'a pas de contexte basé sur la requête.
Question : Comment utiliser la session dans un service Web ?
Réponse : Afin d'utiliser la session dans le service Web, l'appelant du service Web doit effectuer un travail supplémentaire et le cookie utilisé lors de l'appel du service Web doit être enregistré et stocké. Pour plus de détails, veuillez consulter la documentation MSDN pour la propriété HttpWebClientProtocol.CookieContainer. Toutefois, si vous utilisez un serveur proxy pour accéder au service Web en raison de limitations du framework, les deux ne peuvent pas partager la session.
Question : Pourquoi ne puis-je pas utiliser Session lors de la personnalisation de mon propre HttpHandler ?
Réponse : lors de l'implémentation de votre propre HttpHandler, si vous souhaitez utiliser Session, vous devez implémenter l'une des deux interfaces de marquage suivantes : IRequiresSessionState et IReadOnlySessionState. Ces interfaces n'ont aucune méthode à implémenter. la méthode d'utilisation de l'interface INamingContainer.
Q : Lorsque j'utilise une ferme Web, pourquoi la session est-elle perdue lorsque je redirige vers un autre serveur Web ?
Réponse : Pour des informations détaillées, veuillez consulter :
PRB : l'état de session est perdu dans la batterie de serveurs Web si vous utilisez le mode de session SqlServer ou StateServer
http://support.microsoft.com/default.aspx?scid=kb;en-us;325056Q
: Pourquoi ma session est-elle invalide dans la méthode Application_OnAcquireRequestState ?
Réponse : La session ne sera valide qu'après l'appel de l'événement HttpApplication.AcquireRequestState.
Pour des informations détaillées, veuillez vous référer à :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconhandlingpublicevents.asp
Q : Comment puis-je passer d'une page HTTP à HTTPS si le mode sans cookie est utilisé ?
Réponse : Veuillez essayer les méthodes suivantes :
Chaîne originalUrl = "/fxtest3/sub/foo2.aspx";
Chaîne modifiéeUrl = " https://localhost " + Response.ApplyAppPathModifier (originalUrl);
Response.Redirect(modifiedUrl);
Q : La session est valide dans ces événements dans global.asax ?
Réponse : La session n'est valide qu'après l'événement AcquireRequestState, et les événements suivant cet événement peuvent utiliser Session.
Q : Comment enregistrer tous les objets dans la session en cours ?
Réponse : Il peut être obtenu en parcourant toutes les Session.Keys. Le code est le suivant :
ArrayList sessionCollection = new ArrayList();
foreach (chaîne strKey dans Session.Keys){
sessionCollection.Add(Session[strKey]);
}
Q : Est-il possible de partager des sessions dans différentes applications ?
Réponse : Il ne peut pas être partagé directement. Vous pouvez vous référer à la façon de partager une session entre ASP et ASP.NET.
Q : Quelle est la différence entre Session.Abandon et Session.Clear ?
Réponse : La principale différence est que lors de l'utilisation de Session.Abandon, la méthode Session_End (en mode InProc) est appelée. La méthode Session_Start sera déclenchée lors de la prochaine requête. Session.Clear efface uniquement toutes les données de la session et ne termine pas la session, donc ces méthodes ne seront pas appelées.
Question : Afin d'accéder séquentiellement à la valeur d'état de Session, Session fournit-elle un mécanisme de verrouillage ?
Réponse : La session implémente le mécanisme de verrouillage Reader/Writer :
Lorsque la page dispose de capacités d'écriture pour la session (c'est-à-dire que la page possède la balise <%@ Page EnableSessionState="True" %>), la session de la page détient un verrou en écriture jusqu'à ce que la demande soit terminée.
Lorsque la page dispose d'une fonctionnalité de lecture seule pour la session (c'est-à-dire que la page possède la balise <%@ Page EnableSessionState="ReadOnly" %>), la session qui a demandé l'achèvement de la page détient un verrou en lecture.
Un verrou en lecture bloquera un verrou en écriture ; un verrou en lecture ne bloquera pas un verrou en lecture ; un verrou en écriture bloquera tous les verrous en lecture et en écriture. C'est pourquoi lorsque la même page dans deux frames écrit dans la même Session, l'une d'elles doit attendre que l'autre (la plus rapide) se termine avant de commencer à écrire.
Q : Que signifie le délai d'expiration de la session ?
Réponse : Le délai d'expiration fluide de la session signifie que tant que votre page accède (utilise) la session, le délai d'expiration sera actualisé (peut être compris comme un resynchronisation), c'est-à-dire que le délai d'expiration sera recalculé à partir de la demande de la page. Cependant, la page ne peut pas désactiver la session. Il accédera automatiquement à la session de la page actuelle et actualisera le délai d'attente.
Question : Pourquoi la session n'est-elle pas valide dans la fonction de gestion des événements dans global.asax ?
Réponse : Cela dépend de la fonction de gestion d'événements dans laquelle la session est utilisée. La session n'est valide qu'après l'événement AcquireRequestState. Toutes les fonctions de gestion d'événements après cet événement peuvent utiliser Session, mais pas celles qui le précèdent.
Question : Lorsque j'écris un composant qui dépend de la session de l'application actuelle, pourquoi ne puis-je pas utiliser directement Session["Key"] pour obtenir sa valeur ?
Réponse : Session["Key"] est en fait this.Session["Key"], qui est fournie en tant que propriété de Page, vous ne pouvez donc pas utiliser cette propriété directement dans votre composant. Vous pouvez utiliser Session des manières suivantes :
HttpContext.Current.Session["Key"] = "My Seesion Value" ;
Q : Lorsque j'utilise le mode InProc pour enregistrer la session, où la session est-elle enregistrée à ce moment-là ?
Réponse : Différents IIS ont des méthodes de traitement différentes.
Lors de l'utilisation d'IIS5, la session est enregistrée dans l'espace de processus d'aspnet_wp.exe.
Lors de l'utilisation d'IIS6, toutes les applications partagent le pool d'applications par défaut et la session est enregistrée dans l'espace de processus de w3wp.exe.
Q : Le délai d'expiration de la session est-il défini en minutes ou en secondes ?
Réponse : Il s'agit de minutes, la valeur par défaut est de 20 minutes.
Q : Ma session sera-t-elle enregistrée lorsqu'une erreur se produit sur la page ? Je dois effectuer un nettoyage dans Session_End, mais cela échoue, pourquoi ?
Réponse : Session_End ne sera exécuté que lorsque la session s'exécute en mode InProc. Le compte utilisé par Session_End est le compte exécutant le processus de travail aspnet_wp (cela peut être défini dans machine.config). Par conséquent, si vous utilisez la sécurité intégrée pour vous connecter à SQL dans la méthode Session_End, le lien sera ouvert en utilisant le compte du processus aspnet_wp, et le succès ou l'échec à ce moment dépend de vos paramètres de sécurité SQL.
Question : Pourquoi est-ce que je perds la session lorsque je redirige lorsque j'ai défini cookieless sur true ?
Réponse : Lorsque vous utilisez sans cookie, vous devez utiliser des chemins relatifs pour remplacer les chemins absolus dans le programme. Si vous utilisez des chemins absolus, ASP.NET ne pourra pas enregistrer l'ID de session dans l'URL.
Par exemple : remplacez myDirmySubdirdefault.aspx par ..default.aspx.
Question : Comment stocker SortedList dans une session ou un cache ?
Réponse : Veuillez vous référer aux méthodes suivantes :
Liste Sortée x = nouvelle Liste Sortée();
x.Add("Clé1", "ValeurA");
x.Add("Clé2", "ValeurB");
Enregistrer dans la session :
Session["ListeTriée1"] = x;
Utilisez la méthode suivante pour l'obtenir :
SortedList y = (SortedList) Session["SortedList1"];
Il en va de même pour Chahé.
Q : Pourquoi est-ce que je reçois le message d'erreur « L'état de session ne peut être utilisé que lorsque activateSessionState est défini sur true, soit dans un fichier de configuration, soit dans la directive Page » ?
Réponse : Ce problème peut survenir après l'installation de Windows Sharepoint Server (WSS) sur un ordinateur sur lequel l'environnement de développement Microsoft Visual Studio .NET est installé.
Le filtre WSS ISAPI traitera toutes les requêtes. Lorsque vous parcourez une application ASP.NET via un répertoire virtuel, le filtre ISAPI n'attribue pas d'URL au répertoire de dossiers.
La solution est la suivante : n'utilisez pas Session sur la machine sur laquelle WSS est installé.
Pour des informations détaillées, veuillez vous référer à :
L'état de session ne peut pas être utilisé dans ASP.NET avec Windows SharePoint Services
http://support.microsoft.com/default.aspx?scid=kb;en-us;837376Q
: Comment supprimer les variables de session ?
Réponse : Si vous souhaitez supprimer la variable Session, vous pouvez utiliser la méthode HttpSessionState.Remove().
Q : Existe-t-il un moyen de connaître la quantité de mémoire utilisée par la session d'une application pendant son exécution ?
Réponse : Non. À l’heure actuelle, cette valeur ne peut pas être vérifiée, du moins je n’ai encore vu aucune information à ce sujet. Cependant, une valeur peut être estimée approximativement via le moniteur de performances et le code du programme.
Question : Lorsqu'il y a un frameset dans la page, on constate que le SessionID de la page affiché dans chaque frame est différent dans la première requête. Pourquoi ?
Réponse : La raison est que votre frameset est placé sur une page HTML plutôt que sur une page ASPX.
Dans des circonstances normales, si le jeu de cadres est une page aspx, lorsque vous demandez la page, il envoie d'abord la demande au serveur Web, et le SessionID a été obtenu. Ensuite, le navigateur demandera respectivement d'autres pages dans le cadre, de sorte que le frameset soit une page aspx. SessionID de toutes les pages C'est pareil, c'est le SessionID de la page FrameSet.
Cependant, si vous utilisez une page HTML pour créer une page FrameSet, la première requête sera la page HTML. Lorsque la page est renvoyée par le serveur, aucune session n'est générée. Ensuite, le navigateur demandera les pages du Frame, donc celles-ci. les pages généreront leur propre SessionID, donc dans ce cas, ce problème se pose. Lorsque vous actualisez la page, le SessionID sera le même et ce sera le SessionID de la dernière page demandée.
Q : Est-il possible d'enregistrer des sessions de différentes applications sur différentes bases de données sur le même serveur SQL Server.
Réponse : Oui, veuillez vous référer à :
CORRECTIF : l'utilisation d'une base de données SQL pour toutes les applications pour l'état de session SQL Server peut provoquer un goulot d'étranglement
http://support.microsoft.com/default.aspx?scid=kb;en-us;836680Q
: Puis-je obtenir des objets HttpSessionState et HttpContext valides dans Session_End ?
Réponse : Vous pouvez obtenir l’objet HttpSessionState dans cette méthode et y accéder directement à l’aide de Session. Cependant, l'objet HttpContext ne peut pas être obtenu car l'événement n'est associé à aucune requête, il n'y a donc pas d'objet contextuel.
Q : Lorsque j'utilise une session en mode SQL Server, pourquoi ma session n'expire-t-elle pas ?
Réponse : En mode SqlServer, l'expiration de la session est terminée via l'enregistrement de l'agent SQL. Veuillez vérifier si votre agent SQL est en cours d'exécution ?
Q : Après avoir défini EnableSessionState sur "ReadOnly", je peux toujours modifier la valeur de session en mode InProc. Pourquoi ?
Réponse : Même si EnableSessionState est marqué en lecture seule, les utilisateurs peuvent toujours modifier la session en mode InProc. La seule différence est que la Session ne sera pas verrouillée lors de la demande.
Q : Comment puis-je éviter de spécifier un mot de passe lors de la liaison SQL ?
Réponse : Utilisez un lien de confiance ou une chaîne de lien cryptée. Pour plus d’informations à ce sujet, veuillez consulter :
Comment utiliser l'utilitaire ASP.NET pour chiffrer les informations d'identification et les chaînes de connexion à l'état de session
http://support.microsoft.com/default.aspx?scid=kb;en-us;329290Q
: Comment dois-je utiliser Session dans ma propre classe ?
Réponse : Vous pouvez utiliser HttpContext.Current.Session. La méthode spécifique est la suivante :
HttpContext.Current.Session["SessionKey"] = "SessionValue";
De même, vous pouvez utiliser l'objet Application de cette manière.
Q : Pourquoi ma demande est-elle bloquée après le passage en mode SQL Server ?
Réponse : Vérifiez si tous les objets enregistrés dans la session peuvent être enregistrés en mode SQL Server, c'est-à-dire que ces objets doivent prendre en charge la sérialisation.
Question : Quel sera l'impact lorsque la session sera définie sur sans cookie ?
Réponse : Lorsque cookieless est défini sur true, il existe principalement les contraintes suivantes :
1. Les liens absolus ne peuvent pas être utilisés dans la page
2. En plus de basculer entre HTTP et HTTPS, certaines autres étapes doivent être complétées dans l'application.
Si vous envoyez un lien à une autre personne, l'URL contiendra à ce moment les informations d'identification de session, de sorte que les deux personnes partageront une session.
Q : La session peut-elle être enregistrée dans la base de données ?
Réponse : Bien entendu, pour plus de détails, veuillez vous référer à : http://support.microsoft.com/default.aspx?scid=kb;en-us;311209
--------------- -- ------------------------------------------------ -- ------------------------------------------------ -- -
Q : Pourquoi ma session est-elle souvent perdue lorsque je l'utilise en mode InProc ?
Une situation supplémentaire : Si vous utilisez une base de données Access, afin d'éviter le téléchargement de la base de données, certaines personnes peuvent penser à mettre le fichier de la base de données dans le répertoire bin afin que la base de données ne puisse pas être téléchargée cependant si elle est en mode InProc. , cela entraînera également la perte de session. Parce que lors de l'accès à l'application, les données seront fréquemment écrites dans la base de données, ce qui entraînera des modifications dans les fichiers de base de données placés sous le répertoire bin, et les modifications apportées au répertoire bin entraîneront la perte de la session.
Pour résoudre ce problème, vous pouvez modifier le chemin de stockage du fichier de base de données ou utiliser le mode StateServer ou SqlServer.
Pour plus d’informations, veuillez vous référer à :
PRB : les données de session sont perdues lorsque vous utilisez le mode d'état de session ASP.NET InProc
http://support.microsoft.com/default.aspx?scid=kb;en-us;324772
-------------------------------------------------- -----------------------
Session partagée multi-projets dans Asp.net sélectionnée sur le blog de dnyz
http://dev.csdn.net/article/21/21714.shtm
1. Créez une solution vierge, telle que : d:MyProjectMyProject.sln
2. Créez un répertoire racine d'application Web d:MyProjectWebMis sous d:MyProject et définissez-le sur le répertoire virtuel de http://localhost/WebMis
3. Créez de nouveaux répertoires en fonction des modules du répertoire WebMis, tels que : d:MyProjectWebMisLogin et d:MyProjectWebMisCheckOut
4. Créez une nouvelle application Web basée sur le module dans VS.net, telle que : http://localhost/WebMis/Login et http://localhost/WebMis/CheckOut
5. Après la création, les répertoires Login et CheckOut sont automatiquement définis comme répertoires virtuels.
6. Ajoutez des références de projet pour la connexion et le paiement dans le projet WebMis
7. Supprimez les répertoires virtuels de connexion et de paiement dans IIS Manager
8. Supprimez le global.asax de chaque projet (supprimez le projet racine)
9. Supprimez le code suivant dans le web.config du projet (supprimez le projet racine) :
<mode d'authentification="Windows" />
<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" />
Ou supprimez web.config (si vous n'avez pas besoin de le configurer dans chaque répertoire)
10. Après compilation, il peut être exécuté.