..net does not guarantee anything. it minimizes the problem, but does not
eliminate it.
background:
1) each website is really an appdomain. this is the running code.
2) when a page is hit, if it is not in the appdomain, its compiled and added
to the appdomin.
3) if the source of a page is changed, the next time its hit it is
recompiled and added to the appdomain.
4) both the old code and new code exits in the appdomain, so that if a
request is running when a new request comes, the new request gets the new
code
5) if too many pages are recompiled, an appdomain recycle happens. this
means a new appdomain is loaded. as soon as the thread of the old domain
finish its unloaded.
6) an appdomain recyle clears all session data for the inproc session
manager
this all works great if you only use aspx pages and codebehind files. if you
use visual studio, and its code behind model, you can run into timing
problems.
say your app has 2 dlls and three pages:
ui.dll
businessobject. dll
page1.aspx
page2.aspx
page3.aspx
now you start the copying in new files.
here are someways it will fail
1) user hits page3.aspx, it the old code, but the ui.dll has been updated.
the page may be loaded into new appdomain with the new dll, but its not
comaptable with the new dll.
2) user hits page1.aspx., its the new code, but the ui.dll has not arrived,
it loaded with the old dll and doen;t work.
3) you are using inproc sessions, and the appdomain recycles, and your pages
don't handle a cleared session.
you should be able to come up with more cases.
if you have a webfarm, you do a rolling update (pull the server from the
ippool, update and put back.)
if not, you want to do it fast when there is no activity. if its was unix,
you'd copy the site to a temp dir, then swap, but nt will not allow this.
-- bruce (sqlwork.com)
"Stephen Brown" <no****@teluspl anet.net> wrote in message
news:ci******** **@utornnr1pp.g rouptelecom.net ...
We've been using dotNet for a couple of years now and have been updating
our live server by just overwriting (Explorer drag and drop) the aspx and
assembly files until we had some errors reported to us a couple of months
ago that some clients received application server errors at the moment we
updated (if I remember correctly, they were sharing or process in use
errrors). Since then, we've been paranoid about ensuring that there is no
activity when we update, which is awkward to say the least.
I thought dotNet's promise was that there would no longer be any need to
stop services to update the server. Is there a better method to update
assemblies to avoid client errors?
