469,934 Members | 2,227 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,934 developers. It's quick & easy.

Website is not setting Session cookie for asp.net_sessionid

Hi,

I've done some coding in my web application however right now for an unknown
reason my asp.net 2.0 site is not setting asp.net_sessionid cookie and as a
result, I am losing the session data in each page refresh or redirect.

I really do not have any coding against how the session works.
And I have not changed any setting in IIS.

I even compared the 2 code(old and new) bases and didn't see anything funny
which will
cause this.

This truly drives me crazy right now.

Other notes: I've tried this on 3 different machines and it makes the same
behavior on all of them. (old code fine, new code bad)

But I want to repeat again, I am not doing anything related to actual
session

And a final note: After reviewing alot, I realized that before I use the
session object at least once, application does not set "asp.net_sessionid"
cookie.
When I set a dummy variable at least once, it works and sets
"asp.net_sessionid" cookie. However this is still a problem as setting works
after viewing the page for the first time.
As a result cookie is still not availble in the first load but valid
afterwards.

Can someone tell me why my asp.net 2.0 app is not setting this cookie by
default? Am I doing something wrong?

I have the following in my web.config
assemblies:
<add assembly="Microsoft.VisualBasic, Version=8.0.0.0,
Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="System.DirectoryServices, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="System.Design, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="System.Management, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="Microsoft.ReportViewer.WebForms, Version=8.0.0.0,
Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="Microsoft.ReportViewer.Common, Version=8.0.0.0,
Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="ADODB, Version=7.0.3300.0, Culture=neutral,
PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="Microsoft.ReportViewer.ProcessingObjectM odel,
Version=8.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="System.Data.OracleClient, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Windows.Forms, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="Microsoft.Build.Utilities, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="Microsoft.Build.Framework, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
http handler:
<add path="Reserved.ReportViewerWebControl.axd" verb="*"
type="Microsoft.Reporting.WebForms.HttpHandler,
Microsoft.ReportViewer.WebForms, Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" validate="false" />

Aug 12 '07 #1
4 6745
I think this is by design - the Session doesn't "Bake" until a Session item
has actually been set (in ASP.NET 2.0).
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

"SevDer" wrote:
Hi,

I've done some coding in my web application however right now for an unknown
reason my asp.net 2.0 site is not setting asp.net_sessionid cookie and as a
result, I am losing the session data in each page refresh or redirect.

I really do not have any coding against how the session works.
And I have not changed any setting in IIS.

I even compared the 2 code(old and new) bases and didn't see anything funny
which will
cause this.

This truly drives me crazy right now.

Other notes: I've tried this on 3 different machines and it makes the same
behavior on all of them. (old code fine, new code bad)

But I want to repeat again, I am not doing anything related to actual
session

And a final note: After reviewing alot, I realized that before I use the
session object at least once, application does not set "asp.net_sessionid"
cookie.
When I set a dummy variable at least once, it works and sets
"asp.net_sessionid" cookie. However this is still a problem as setting works
after viewing the page for the first time.
As a result cookie is still not availble in the first load but valid
afterwards.

Can someone tell me why my asp.net 2.0 app is not setting this cookie by
default? Am I doing something wrong?

I have the following in my web.config
assemblies:
<add assembly="Microsoft.VisualBasic, Version=8.0.0.0,
Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="System.DirectoryServices, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="System.Design, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="System.Management, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="Microsoft.ReportViewer.WebForms, Version=8.0.0.0,
Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="Microsoft.ReportViewer.Common, Version=8.0.0.0,
Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="ADODB, Version=7.0.3300.0, Culture=neutral,
PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="Microsoft.ReportViewer.ProcessingObjectM odel,
Version=8.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="System.Data.OracleClient, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Windows.Forms, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="Microsoft.Build.Utilities, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="Microsoft.Build.Framework, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
http handler:
<add path="Reserved.ReportViewerWebControl.axd" verb="*"
type="Microsoft.Reporting.WebForms.HttpHandler,
Microsoft.ReportViewer.WebForms, Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" validate="false" />

Aug 12 '07 #2
Hi SevDer,

How are you doing? Have you got any progress on this issue?
Please feel free to post here if there is still anything we can help.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.
Aug 15 '07 #3
Hi Steven,

Just to clarify the issues I'm having.
I've solved the issue by setting a dummy session variable even though I am
not using it.

Now why do I need session when I don't directly use it?
Because I use a syncronized static hashtable where I access the active item
for the session throught the sessionid. My reason for this is because there
are threads working on active object in the hashtable for that session. This
is why I need the session eventhough I don't use it directly.

I hope I made it clear...
SevDer

"Steven Cheng[MSFT]" <st*****@online.microsoft.comwrote in message
news:nS**************@TK2MSFTNGHUB02.phx.gbl...
Hi SevDer,

How are you doing? Have you got any progress on this issue?
Please feel free to post here if there is still anything we can help.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no
rights.

Aug 21 '07 #4
Thanks for your followup SevDer,

Now I've got your detailed problem scenario. Yes, I agree that make the
sessionID fixed is quite important in your design.

Thanks again for your posting!

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Aug 21 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Jimmy Junatas | last post: by
1 post views Thread by Daniel Michaeloff | last post: by
3 posts views Thread by Alex Nitulescu | last post: by
reply views Thread by briand | last post: by
13 posts views Thread by Alexander Widera | last post: by
2 posts views Thread by Vikas | last post: by
1 post views Thread by ALA | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.