webforms - changing APP_Code classes kicks users out

Question

Hi all,
I'm pretty sure there is nothing I can do about this but wanted to ask anyway.

I have a webforms 4.7fw app hosted internally (not internet facing). with 60 users on it.
users login using IIS forms authentication. once authorized i pull back some user details into global.asax as session variables that can be used whilst the user is logged in.

During the day whilst users are logged in, when I change a class in the App_code folder, it kicks the users out. I'm guessing thats IIS is recompiling the changes and clears down its stored cache of users.

Is there any way around this?
at the minute I develop during the day and only release on an evening when everyone finishes work.

tia
Dave

Answer 1

There is nothing you can do about it, any change in APP_Code folder, web.config/global.asax files fires a recompile, this is by design.
After recompile, site will be up but not loaded, it get´s loaded on first access.
Logged users, have to login again. Or upload your changes during off-time
You can know more about at
reset-restart-recycle-iis
reasons-for-aspnet-application-restarts-on-iis-server

Answer 2

You can use an out of process state manager like Sqlserver, so state survives a recycle and set the machine keys in the web.config so the encryption keys are not regenerated on a recycle.

Answer 3

If you change most anything in the app's code (including the config) then it'll reset the app which "kicks everyone out". But that isn't quite how session works. If you're using forms auth then most likely you are using cookie authentication. When the user logs in then they get a session created for them in memory (in most cases). What you store there is up to you. You should really only be storing data that is specific to that user.

The user's authentication information gets sent back to the browser as a cookie. Subsequent calls to the server generally pass the session ID back which the server then uses to find session, if any. If the session has expired or isn't available then a new one will be created. Any data in the old session is gone but normally you only use session for cached data anyway so it is no big deal.

The user's authentication should still be valid as they still have their cookie. Hence they may lose their cached data but they shouldn't be kicked out of the system as they still have a valid cookie that the server will use. Hence you can normally bounce an app while users are logged in and they won't really notice. In fact most apps idle out so this probably happens more than you think.

So I would say that if your users are being forced to log back into your system then your app isn't managing the authentication cookie properly. This isn't anything to do with session. You should resolve that issue.

As for updating an app while users are actively using it I would generally recommend against that anyway. When you deploy the app it'll go down for a second which means users may catch the downtime. Things could also go wrong or take longer to start up so bringing a business app down during business hours isn't something you should probably be doing even if you didn't have an authentication issue. Business apps should probably be updated after hours. If you have a build server or equivalent then schedule nightly releases or something while everyone is out of office.

Answer 4

Thanks for all the suggestions guys. i figured id have to carry on as is.. just wanted to check.

thanks
Dave