Session state service will work fine even after installing .net framework 2.0 SP2

  • Article
I recently got to know about a slightly different observation on sessionstate behavior using the asp.net state server service after having installed .NET framework Service Pack 2 (SP2).

The new behavior may cause some confusion about whether sessionstate is still properly maintained by the asp.net state server service. In general I would like to clear out that basic functionality is not affected.

The following walkthrough will demonstrate the new behavior:

- Create two separate web applications below a single website in IIS. Ensure the web applications are mapped as separate web applications in IIS. You can use Visual Studio to create them either based on a 'web application' or a 'website' project template.

- On each projects default.aspx add one asp.net label control 'Label1' and one asp.net button control 'Button1'.

- Ensure both applications are configured to maintain session state using the asp.net state server service provider.

- Assign the value for System.Web.HttpContext.Current.Session.IsNewSession to the labels text property and print the SessionID from both the Page_Load and Button1_Click events. If you created a visual basic asp.net application modify the event handlers procedures as follows:

    Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click

        Label1.Text = System.Web.HttpContext.Current.Session.IsNewSession

        Response.Write(Session.SessionID.ToString() + " (Button1_Click)<BR>")

    End Sub

    Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

        Label1.Text = System.Web.HttpContext.Current.Session.IsNewSession

        Response.Write(Session.SessionID.ToString() + " (Page_Load)<BR>")

    End Sub

- Now start IE7 or IE8 and open two separate tabs. On the first tab navigate to default.aspx of the first web application. On the second tab navigate to default.aspx of the second web application.

- Observed results are:

* The displayed text for the label in both pages shows "True". A new session was generated as expected.

* Both pages show an identical SessionID

- Now click on each pages button to observe the following:

For Web Application1, the label text displays "False". This persists for subsequent postbacks.

For Web Application2, the label text displays "True". This persists for subsequent postbacks.

It appears we do get a new session only for the second tab.

Before ASP.NET 2.0 SP2, you would notice the label text displays "False" after clicking the button in the second tab and for each subsequent postback.

For any of those scenarios the printed SessionIDs for both applications are identical.

The observed behavior may cause confusion on whether session state maintenance across postbacks persists or whether it's isolated for different web applications.

This behavior is by design. You simply cannot rely on the values until you store some data in session scope.

ASP.NET does create the various session objects but drops them right after the page execution unless some data is stored in them.

To observe reliable results you need to store data in session scope. This will ensure sessionobjects are properly persisted.

Simply extend the sample above and notice that IsNewSession properly returns false on subsequent postbacks, and SessionIDs for different applications are unique.

Read more about unique sessionIDs in article

"How and why session IDs are reused in ASP.NET" at https://support.microsoft.com/kb/899918