+1  A: 

Peter, it is better that you centralize the session access.

public class SessionStateBag
{
    private static string SessionPropertyXKey = "SessionPropertyX";
    public static int SessionPropertyX
    {
        get { return Session[SessionPropertyXKey]; }
        set { Session[SessionPropertyXKey] = value; }
    }

    private static string SessionPropertyYKey = "SessionPropertyY";
    public static string SessionPropertyY
    {
        get { return Session[SessionPropertyYKey]; }
        set { Session[SessionPropertyYKey] = value; }
    }

    // etc. Try to guess the type of the session property. If you cannot guess it; use object.
}

In the rest of the code, replace Session["xxx"] with one of the properties of SessionStateBag above.

This might take you a day or two, but you will have all session access on one place and you have the ability to have insight in the maze the Session object sometimes creates.

bartvdvliet
Thanks, but that doesn't answer the question. I'm working in a large legacy codebase where doing this isn't practical, since there is little test coverage in place.
Peter Mounce
How large can a codebase be that find/replace wouldn't make this a fairly simple refactor? Granted this isn't a direct answer to the exact question, but seems to me this is an excellent suggestion to help you improve your debugging. I work on a fairly large codebase myself, if the session object was a problem for us (we don't use it heavily) I would consider doing something like this
DannykPowell
It's not the size so much as the codebase isn't wrapped in _any_ test-coverage yet. The chances of missing a key where it has been concat'd together, for example, are too high.
Peter Mounce
+1  A: 

Have you tried this one from Codeproject? After correcting the Reference to Microsoft.VisualStudio.DebuggerVisualizers from version 9.0 to 10.0 it worked in vs2010.

Installation folder is:

C:\Program files\Microsoft Visual Studio 10.0\Common7\Packages\Debugger\Visualizers

Thomas Schreiner