aspnet deploy

[Paulo Roberto Bianchi de Oliveira]

Hi, we hit Publish WebSite on VS it generates the compiled site on some
folder. So we overwrite the whole structure (skip web.config) on production
enviroment... If there's some user doing anything shows him/her a error
message. So he/she has to do logon again and ok...

because on old asp we just overwrite the modified asp file and no
problems...

What you suggest? Is it the right way of deploying the new webapp version?

Thank you!

 

[Andy O'Neill]

Hi, we hit Publish WebSite on VS it generates the compiled site on some
folder. So we overwrite the whole structure (skip web.config) on
production enviroment... If there's some user doing anything shows him/her
a error message. So he/she has to do logon again and ok...

because on old asp we just overwrite the modified asp file and no
problems...

What you suggest? Is it the right way of deploying the new webapp version?

Thank you!

I'm surprised they get an error.
I would have expected shadow copying to handle this situation.
I thought logged on users would carry on using the old version of your site,

I would usually do any upgrade at a time when I could expect minimal users
though.
There again I would usually create an install msi and use that or xcopy.
Maybe there's some subtle difference there.

 

[Andrew Morton]

Hi, we hit Publish WebSite on VS it generates the compiled site on
some folder. So we overwrite the whole structure (skip web.config) on
production enviroment... If there's some user doing anything shows
him/her a error message. So he/she has to do logon again and ok...

And what is that error message?

What happens if you configure the site to use out-of-process application
state?
"ASP.NET Session State Overview"
http://msdn.microsoft.com/en-us/library/ms178581.aspx

 

[shusta guthnar]

And what is that error message?

What happens if you configure the site to use out-of-process application
state?
"ASP.NET Session State Overview"http://msdn.microsoft.com/en-us/library/ms178581.aspx

Mr. An Drew we'll have much confusions. When publish VS site you are
haveing overwrite of all files. When executeing such buildings VS
creates 'application_offline.aspx' file. This would be haveing such
effect as message to user and rubbish collect valid session. So re-
login would surely happen. There is not having a valid sessioning?!!?

 

[Gregory A. Beamer]

Hi, we hit Publish WebSite on VS it generates the compiled site on some
folder. So we overwrite the whole structure (skip web.config) on
production enviroment... If there's some user doing anything shows him/her
a error message. So he/she has to do logon again and ok...

because on old asp we just overwrite the modified asp file and no
problems...

What you suggest? Is it the right way of deploying the new webapp version?

Without a web farm, you cannot completely avoid errors (and even then
interface changes may lead to errors), as the app (or page) must recycle at
some time (whether you do it or it is done by what you copy). If you copy a
full app that is precompiled, you need to restart that app. There is no real
way around it.

There are ways of reducing the pain, however. One prime method is moving
session state to either session server or SQL Server. The person who is in
the middle of a click right when you deploy will still have problems
(assuming a single server), but others will not, as the session state will
be retrieved and they will continue as if the app had not updated. Note,
however, if you change the page they are working on, they can still have
errors.

Another method to reduce errors is not pre-compiling the site (using web
site model, rather than web application). In this model, each page is
recompiled on the fly. The downside is JIT per page, so there is both good
and bad. I don't prefer this model, but it does allow you to update single
pages. That could be a good thing or a maintenance nightmare.

I use the method you use, but keep session state off the box. In general, I
have used SQL for session state. It is a bit slower, but there are some
advantages for what I have worked on. I then move the bits to the same box
in a deploy "test" folder, where I make sure I don't have any obvious
errors. We then move everything but config over, which usually takes a
second or two. I then restart the web app, which takes a few more seconds.
As the state is in SQL Server, the user gets no error when he submits the
form he is on, unless he is unlucky enough to do it in the few seconds of
downtime.

On most apps, I use a web farm with separated session state (realistically
the only way you can do it unless you have sticky sessions, which kind of
overrides one of the reason for farming). I can then deploy to one machine
at a time. NOTE that there is still a possibility of altered UI breaking the
user's session, especially in apps that use viewstate.

--
Peace and Grace,
Greg

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

************************************************
| Think outside the box! |
************************************************