8

If so; where can I get it?

Peter Mounce
  • 4,105
  • 3
  • 34
  • 65
  • Do you realise that when you hit a breakpoint you can just bring up the Immediate debugger window and type 'Page.Session' to see it? – slugster Apr 26 '10 at 10:11
  • Yes. I was hoping for a visualizer that would show me a structured view of each object present in the session, in some magical manner that didn't require me to have a watch on the keys I was interested in. I'm reverse-engineering deeply nested legacy code, and want to set a breakpoint where I'm interested, but not on every session-access. – Peter Mounce Apr 26 '10 at 11:12

2 Answers2

2

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.

badabadabada
  • 141
  • 8
  • 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 Apr 28 '10 at 10:59
  • 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 May 04 '10 at 08:08
  • 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 May 09 '10 at 13:31
2

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
  • 2,137
  • 1
  • 17
  • 38
  • Unfortunately the SessionVisualizer window is modal and not dockable, but hey it works! Note: your session objects need to be serializable to show the data in the viewer, though you can see the name and type of all objects in the list. Handy! – Mark A May 06 '11 at 13:40