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