If I change (and upload) the web.config of an ASP.NET site, do existing users surfing the site lose their sessions?
Also, does the IIS server need to be reset?
If the session is in proc, then yes, they do loose their sessions.
If you are using a session server then no, they don't.
A new web.config would cause a restart of the site automaticlly, but should not require an IIS reset.
Modifying the web.config file will cause the application to restart an it is equivalent to recycling the application pool. If you are using InProc session management, then yes, all user sessions will be lost. No, an IIS reset is not needed.
Related
If I modify an object on web.config that populates a combobox in a web application that is in a staging area or even production, do I need to restart the IIS or it detects that the web.config was changed?
Sorry for the silly question
Ty
Changes to configuration settings in Web.config files indirectly cause
the application domain to restart. This behavior occurs by design.
From MSDN
any change to the web.config will initiate a recycle of the application pool, you do not need to restart anything.
I am running ASP.NET 4.0 website (not a web project) , which is frequently modifying. Pages updates smoothly ,but some key file ,like web.config or resource files updates causes web site restarting and throws users from site, make them log in again and lose their sessions.
What are the possible ways of solving the problem.Ideal scenario is to allow existed users to work with old version and newly logged to work with new one.
You could use a different session storage mode such as StateServer or SQLServer. Read more about the state modes http://msdn.microsoft.com/en-us/library/ms178586(v=vs.100).aspx. By default ASP.NET uses InProc session storage, which are lost whenever the application pool refreshes (such as when the web.config file is changed).
Here is another article on MSDN that walks you through how to set up SQLServer sessions: http://support.microsoft.com/kb/317604
I have deployed two web applications on my IIS7.
The problem is, IIS is generating the same Session.SessionID if I request both application using the same browswer (different tabs).
This is causing some problem with ASP.Net user authentication, it is some how overlapping with each other and the flag "User.Identity.IsAuthenticated" returns false whenever the user logs in on to the other site. It works fine as long as user is working on one of the site.
Please help me out, I cant seem to find the reason for this, I mean the session is application specific so why is sessionID from one web app is conflicting with the other.
Thanks
They are running in the same application pool. Just separate the application pools.
Problem is your browser is treating these applications the same. Session in ASP.NET is implemented by the session cookie. These need to have different website names so that they do not share the same session.
UPDATE
This is how session cookie works.
But one solution is to access them as mysite.com/1 and mysite.com/2. That I believe should also work.
Did you checked application pools, if you want to isolate web application you should define different application pools.
Is each application running in a separate IIS Application? If they are, then the session will be separate, as Session is scoped to the AppDomain. If they are in the same IIS application, they are loaded in the same AppDomain, and will share Session.
In the same browser session (regardless of using tabs), the same Session cookie will be sent.
I dislike it when I lose the session state of my ASP.NET web app when changing code.
Losing the session state means I have to log in over and over again. It's annoying.
Is there anyway I can reconfigure my app so that I can make changes to code and not have to re-authenticate to view those changes?
(I know that changing .ASPX files does this fine. My concern is over App_Code and Bin compiled code.)
Unfortunately changes in the web.config or in dll's in the bin folder will cause an application reload and there is nothing you can do about it, AFAIK.
I wonder what will happen if you will store session state in StateServer. Maybe it will work ( I will be surprised if it does).
If you are in a developer environment you can try disabling logging into the site, or when the site checks for authentication just return your default authentication. For production, a StateServer will help as Igal pointed out.
One last option, store the login information in Session, but as a backup to that use a login table in your database to be able to restore a user's authentication status from a cookie. Obviously, consider security implications.
By changing your StateServer to use your machine (enabling the ASP.NET State Service), you won't lose your login.
If I add "trace=true" into my directive on an asp.net 2.0 .aspx page, will it recycle my application pool?
I know if I enable tracing in web.config that will recycle the application pool.
The webserver is IIS 6.0.
Thanks.
I'm not 100% sure but it shouldn't. Any change to a web.config file would cause an app pool reset, but a page level change shouldn't even in the directive.
Check out the section "Why does an application domain recycle?" in this link
Technically if it's the 15th re-compile it could cause a reset... but other than that no.
I believe it will just trigger a recompile of that page. Editing of an aspx file is not a trigger for an application restart.
Why not test it out and see?
Ok - I just tried it out on a testing server - adding in the "trace=true" directive on the page level did NOT recycle the application pool.
It won't. the app pool only recycles when a dll is changed in the Bin directory or if the web.config file is changed. If you are concerned about loosing your session info as that is what the question seems to me to be more related to then you can use the asp.net session state provider and that way your app pool can recycle as many times as it likes without you loosing your session.