deployment/publishing of aspnet apps...

[Terry Mulvany]

Hello group,
Curious as to how you all have chosen to deploy/publish your asp.net apps.
Currently though we have a local dev environment, then we stage to a QA
server then we publish/deploy.
In previous jobs I've always used straight xcopy to publish to production
(usually via the Copy Project option in VS.Net). The way I understand it,
your choices are you can xcopy or use an MSI. What are the benefits of each
and if there is no need to register anything (i.e. activex components, etc.)
why would an MSI ever be used?

Thanks Group.

-Terry

[Andy Fish]

MSI Offers many advantages if you are producing a packaged product which may
be installed by other people. For instance, it will appear on the add/remove
programs control panel.

Also you can do other stuff at installation time (automatically create and
configure virtual roots, create databases, install and configure third-party
components, set file permissions, even install the .net framework if you
want)

MSI is a lot more work though (depending on the level of functionality
you're trying to achieve). If you work for an IT department deploying to
your own servers, it's unlikely to be worth the effort

Just my $0.02

Andy

"Terry Mulvany" <te***********@rouseservices.com> wrote in message
news:uH*************@TK2MSFTNGP12.phx.gbl...

Hello group,
Curious as to how you all have chosen to deploy/publish your asp.net apps.
Currently though we have a local dev environment, then we stage to a QA
server then we publish/deploy.
In previous jobs I've always used straight xcopy to publish to production
(usually via the Copy Project option in VS.Net). The way I understand it,
your choices are you can xcopy or use an MSI. What are the benefits of
each and if there is no need to register anything (i.e. activex
components, etc.) why would an MSI ever be used?

Thanks Group.

-Terry

[JiangZemin]

I like to do MSIs to install on a staging machine. Then do xcopy with batch
file from this staging machine to either QA or production, then do secondary
xcopy for web.config files, for example, to control if datasources are
QA/production (remember to take each server offline in the time between
config file update if u do this, however, to prevent live user from hitting
wrong config file in that time period).

This helps ensure that the same build is on QA and production. Less chance
of an embarassed developer sneaking some quick fix MSI into production
servers. Its much easier than doing MSI installs on each server in a web
farm, and you dont need to manually deal with the config files at all (or
even worse create different MSIs for QA/production).

HTH,
Premier JiangZemin

"Terry Mulvany" <te***********@rouseservices.com> wrote in message
news:uH*************@TK2MSFTNGP12.phx.gbl...

Hello group,
Curious as to how you all have chosen to deploy/publish your asp.net apps.
Currently though we have a local dev environment, then we stage to a QA
server then we publish/deploy.
In previous jobs I've always used straight xcopy to publish to production
(usually via the Copy Project option in VS.Net). The way I understand it,
your choices are you can xcopy or use an MSI. What are the benefits of
each and if there is no need to register anything (i.e. activex
components, etc.) why would an MSI ever be used?

Thanks Group.

-Terry