Joe,

I'm not sure I quite understand what you're doing, but whatever you store in the session should be relatively lightweight. It should contain only what you need and should be easily serializable.

I'm not sure what Web Client does but if it's what you're trying to serialize you'll have problems because you have a ref to a Context object that won't serialize right.

Loading and storing the session var can be tricky, but it usually depends on the app/page that you're dealing with. There's no standard way to do this because you'll load in Page_load usually and you'll write after any update operation (ie. button clicks and the like). Really, just think of the session as your data store and treat it like you would database accees and you have the right idea. The only additional thing you probably need to do is clear out the session data when you're done. No need to clutter up session store with this stuff once its not needed anymore.

+++ Rick ---

>>>>I have a web app that is wizard style. I want to save my user input into a class that persists from page to page. Anyone know how to do this? I cannot parametize the data and I don't want to create 75+ session variables. :(
>>>>
>>>>My humble thanks in advance,
>>>
>>>Create a class to encapsulate all the data and put that into your session. If you have a high amount of users at one time you may want to use the database, cause as you said alot of stuff stored in session really affects the IIS memory. You'd be surprised how fast you can pull this stuff out of the sql db on each hit.
>>>
>>>And as I said, it scales much better. Also, if you use a web garden or web farm and you wanted this to work you would have to use out-of-proc or sql session store which is MUCH slower than in-proc... or you would have to use sticky ips.
>>
>>Be careful with those recommendations <g>. Yeah InProc is much faster but I would basically never recommend you use it because there are just too many instances where the app can get blown away from AppDomain restarts.
>>
>>Also, raw SQL access isn't going to be any faster than SQL Session output, so I think using a session is still a good call.
>>
>>Batching a bunch of variables into a single object is good form though - I do this all the time and it makes coding much nicer because you can fill this objects much more easily and keep it synched to your data than using a bunch of separate sessions vars. In fact, in many of my apps I data bind directly against these session container objects and only write them out at the end which means a typcial request accesses the session only twice (once to read, and once to write). This is a great way to go even if the persistence of this object is a little more expensive than writing out single values.
>>
>>
>>+++ Rick ---
>>
>>>
>>>BOb
>
>This is my thinking as well. Where I have questions is after I have created my class, now what? < g >
>in the global.asax I should I have

>Public Class Global
>    Inherits System.Web.HttpApplication
>    Friend MyClient As New WebClient
>...
>

>beyond this I have not been able to figure out how access the instanciated class from the individual pages. I also have some worker classes (that are not in/on web forms) that I would have to create a property or pass context.session in order to use session vars.
>
>So in summary, I have my class and beyond that I don't really know what would be the best solution. It is a shame I cant reference global.MyClient in the example above without re-instanciating it?
>
>Is it poor form to inherit System.Web.UI.Page in a class?
>Is it better to do something like this;

Imports System.Web
>Public Class WebClient
>    Private m_CurContext As HttpContext
>    Public Sub New()
>        m_CurContext = System.Web.HttpContext.Current
>    End Sub
>...
>

and just slam my object into a session var on the first page load?
>
>My humble thanks in advance,