Good point. Just be sure to close the browser to start a new session if you mess with the code that handles session data.
--b Bryan Batchelder eBusiness Consultant ConnectWise, Inc. 813-935-7100 x 425 > -----Original Message----- > From: Thomas Tomiczek [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 14, 2002 1:05 PM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] ASP.NET Session Expiration > > > But be carefull in this case - when you chane the data stored > in the session object, you need to handle this manually. > > > Regards > > Thomas Tomiczek > THONA Consulting Ltd. > (Microsoft MVP C#/.NET) > > -----Original Message----- > From: Marsh, Drew [mailto:[EMAIL PROTECTED]] > Sent: Freitag, 14. Juni 2002 19:01 > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] ASP.NET Session Expiration > > Houck, Rob [mailto:[EMAIL PROTECTED]] wrote: > > > Or.. Am I seeing something that only would occur on our development > > servers (caused by the *build* operation) and would not happen in > > production (caused by copying new DLL's to the production box)? > > I'm quite sure you'll see this in both scenarios, because in > both cases it's the updating/replacing of the assemblies it > depends on that is forcing the web application to "restart". > If you need the session to stay around when the application > is restarted then, as you suspected, you'll need to run > session state out of proc. > > HTH, > Drew > > [ .NET MVP | weblog: http://radio.weblogs.com/0104813/ > > You can read messages from the DOTNET archive, unsubscribe > from DOTNET, or subscribe to other DevelopMentor lists at > http://discuss.develop.com. > > You can read messages from the > DOTNET archive, unsubscribe from DOTNET, or subscribe to > other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
