Session issue with VWD

Bob Bedell · December 25th, 2007, 04:24 PM

Hello,

I have an odd issue with VWD, though I don't know that is is specific to VWD. I have some code in a Global.asax file that sets a custom princial object for the session in the Application_AcquireRequestState event.

When I run the app (CSLA's PTWeb) in VWD, the code breaks in the Application_AcquireRequestState event at this (the first) line:

Code:

if (Session["CSLA-Principal"] != null)

The error is:

Code:

Session state is not available in this context.

However, the program compiles correctly and when I launch it in IE, it runs correctly too. Perfectly.

Anyone ever encounter anything like this? The app won't run in VWD because a Session object isn't instantiated (apparently) at the time the Application_AcquireRequestState event fires, but the compiled app runs fine on IIS and in IE. Should also mention I didn't have this problem running the app in .NET 1.1/VS 2003. The Global.aspx event fired fine and set the CurrentPrincipal.

Hmm...

Is the Session object not available at this point under .Net 2.0 or something weird like that?

Thanks as always,

Bob

My Global.asax event:

Code:

public class Global : System.Web.HttpApplication 
{

    public Global()
    {
        InitializeComponent();
    }



    protected void Application_AcquireRequestState(Object sender, EventArgs e)
    {
        // set the security principal to custom BusinessPrincipal
        if (Session["CSLA-Principal"] != null)
        {
            Thread.CurrentPrincipal = (IPrincipal)Session["CSLA-Principal"];
            HttpContext.Current.User = Thread.CurrentPrincipal;
        }
        else
        {
            if (Thread.CurrentPrincipal.Identity.IsAuthenticated)
            {
                System.Web.Security.FormsAuthentication.SignOut();
                Server.Transfer("Login.aspx");
            }
        }
    }

    private void InitializeComponent()
    {

        this.AcquireRequestState += new System.EventHandler(this.Application_AcquireRequestState);

    }
}

Bob Bedell · December 25th, 2007, 05:29 PM

BUT...when I run the app in Debug...

The code breaks at

Code:

if (Session["CSLA-Principal"] != null)

sometimes. If it does break here, it cycles back through this line of code a couple of times until, apparently, session state IS available.

EVENTUALLY, the session state becomes available, and the app proceeds correctly. I get the same behavior on subsequent page requests.

It almost like there is a delay in initializing session state, and when I run the app in debug mode, app processing slows down enough to allow session state to be initialized? I'm just reaching here. But have no idea what else could be going on. Any thoughts?

Bob

Bob Bedell · December 25th, 2007, 05:38 PM

Oh, and...

This is largely immaterial to the behavior I'm asking about, but I went back to a .NET 2.0 style Global.asax page. Don't know why after inventing CodeBehind MS reverted to in-line script for just these pages, but here it is:

Code:

<%@ Application Language="C#" %>

<script runat="server">

    void Application_Start(object sender, EventArgs e){}
    void Application_End(object sender, EventArgs e){} 
    void Application_Error(object sender, EventArgs e){}
    void Session_Start(object sender, EventArgs e){} 
    void Session_End(object sender, EventArgs e){} 
    protected void Application_AcquireRequestState(Object sender, EventArgs e)
    {

        // set the security principal to custom BusinessPrincipal
        if (Session["CSLA-Principal"] != null)
        {
            System.Threading.Thread.CurrentPrincipal = (System.Security.Principal.IPrincipal)Session["CSLA-Principal"];
            HttpContext.Current.User = System.Threading.Thread.CurrentPrincipal;
        }
        else
        {
            if (System.Threading.Thread.CurrentPrincipal.Identity.IsAuthenticated)
            {
                System.Web.Security.FormsAuthentication.SignOut();
                Server.Transfer("Login.aspx");
            }
        }
    }

</script>

Bob

Bob Bedell · December 26th, 2007, 04:20 AM

I guess this issue is pretty much resolved. Seems like i can just F-11 through it until session state catches up. Good enough for me.

Bob