I thought I post this little tip that has saved me a lot of shitty debugging today. You might find this useful…

When you use Session state in ASP.Net to store an object, then use Trace on the page to view the content of the Session object, Trace shows you a nice list of all the Session vars and their content. For most custom objects you don't much get info though: It returns the name of the class, which is the default implementation of ToString().

If you want useful information override the ToString() method on your custom class and return a string that contains the content of your class. You can use a fairly generic routine to do this fairly easily. You’d put something like this into your custom class:

public override string ToString()
{
      return Westwind.Tools.wwUtils.ObjectToString(this," | ");
} 

And then implement a static method to take this call:

public static string ObjectToString(object Obj, string Separator)

{

      FieldInfo[] fi = Obj.GetType().GetFields();

      string lcOutput = "";

      foreach (FieldInfo Field in fi)

      {

            lcOutput = lcOutput + Field.Name + ": " + Field.GetValue(Obj).ToString() + Separator;

      }

      return lcOutput;

}

This code uses Reflection to loop through each of the fields of the object and dump out the content of each using ToString(). This gives you a quick view of the top level property state of the object, which makes debugging objects in ASP.Net Sessions a hell of a lot more useful and might save you some trips back to the Debugger and digging into the properties explicitly. Here’s what it looks like on the Trace page:

This came about as I was refactoring some code today in the West Wind Web Store base that deals with taking 10 or so individual Session Variables and consolidating them into a single strongly typed object. Using individual Session vars is easy enough but because they aren’t strongly typed you end up having to always write check code to make sure that the variable is there and convert it back into the proper type.

Using an objects can reduce that code to a single check to see if the object exists and if not creating a new instance of it (with default values set).  After that you're simply talking to an object with properties. It made a lot of sense in my current app as there were about 20-30 lines of code on a bunch of pages dealing just with the Session Var initialization. That code has now been reduced to 4. It surely would make even more sense with more complex data pieces stored into Session.

Remember that any object that that can be stored into the Session object must be seariaizable – ie. Inherit from MarshalByRef or be marked with the [Serializable()] Attribute. Also keep in mind there’s a little overhead in the serialization that’s performed on the object. However, this overhead is minimal on small objects and is probably made up by not having to do the type conversions later on.