Adam, I agree (and our experience bears it out), IIS reset should kill off any thing that the web app is doing (actually we rarely even need to do that. Unless is some of the web application code is in COM+, that can have a life of its own.
Michael -----Original Message----- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Thursday, 22 January 2009 8:28 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Prevent reboot. Michael, Well yea that will be sorta the case. Some people will probably be in the middle of using the site (if the poor souls are sad enough or getting close to dead line to feel the need to work during lunch :-) ), not had chance to tell it to send out a warning email yet ... although they should know by now when it is going to happen, when suddenly the process stops IIS and copies the MSI to a place accessible by the server then installs it (the MSI is about 30MB for the website, with our poor network at this time we are talking several (10-20) seconds before its copied and started the install which I feel is enough time for IIS to release the locks on any dlls). At least with the services I can understand Windows Installer maybe being too quick to start installing before we its let the service settle (althought like i said I would think its smarter than that) but the website I am a bit stumped with. Adam On Wednesday 21 January 2009 22:10:55 Michael Osmond wrote: > Adam, > > I suspect there is something more going on here. We have been > following a test deployment process like yours for several years for a > suite of large web applications, and the only time we have file lock > issues is if someone is actively testing (hitting the pages) when the upgrade occurs. > > > Michael > > -----Original Message----- > From: Adam Burton [mailto:adz...@googlemail.com] > Sent: Thursday, 22 January 2009 5:53 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Prevent reboot. > > I don't know about that. I can understand why it gets the locks etc, > but its the releasing that seems to mess up for me, or behave in a > manor I would not except. For example the services I install ... why > are files still locked when the msi stops the service ... the service > is the only thing that will use those file ... I can't see why I > should need to stop the service for the msi before hand. Same with the > IIS files, IIS is stopped, it should release those DLLs that are only > accessed by IIS (they live in the website 'bin' directory, surely once > IIS is stopped it has no use for them and should release them). I have > just always assumed that it is a separate service/process/thread that > releases the locks and its just too slow off the mark for the MSI. If > that is the case though then you'd think there'd be stuff in Windows > Installer that would take that into account so I'd at least only be > rebooting every so often rather than a majority of the time. > > Also its not uncommon for me to delete a directory and the directory > wont go away. With some inspection using stuff like process explorer > it appears "System" has a lock on it (presumably for shi**z and > giggles), soon as you kill the handle the directory goes. While the > lock idea is sane, Windows implementation doesn't seem to work for me, > therefore in its current state it's not sane for me :-). > > Before anyone thinks I am Windows bashing this is just one of the > gripes I have with Windows, I have plenty of gripes with other OS's too. > Although I have to say on the plus side I am yet to encounter the > issue in Vista, but that being said I don't tend to delete directories > often or install already running services in Vista so maybe I've just > not trodden the path :-). > > Regardless I must be doing something else wrong because even if I got > the file's name from the log file I still wouldn't know where to start. > Anything that is supposed to use the files, in the case of IIS, is > shut down and for the services it is shut down by Windows installer > which I would think is smart enough to handle a situation like > shutting down the service correctly so any files locked only by it > will be released sometimes preventing the requirement of a reboot. > > On Wednesday 21 January 2009 18:03:05 Rob Mensching wrote: > > MSI verbose log file should point out the file being locked. Then > > you > > > just need to figure out how to get the thing to be unlocked. That's > > how Windows works. It's perfectly sane, just not always very > > convenient. <smile/> > > > > -----Original Message----- > > From: Adam Burton [mailto:adz...@googlemail.com] > > Sent: Wednesday, January 21, 2009 06:00 > > To: WiX-users@lists.sourceforge.net > > Subject: [WiX-users] Prevent reboot. > > > > Hi, > > I have created some WiX based installers for some services and a web > > application I am working on at work. We use the installers as part > > of our test rigs, so we patch our test changes, build the new > > version and > > > install it. Since this whole process is automated if the MSI > > determines it needs to reboot, it will. > > > > Previously when I installed the services it would cause a reboot, I > > assume due to file locks even though the installer would stop the > > service. My resolution was to stop the service before performing the > > upgrade, this seems to have solved that issue, although it seems > > unnecessary. I am now getting the same problem with the Web > > Application. It automatically deploys a new test build 2 times > > during the day, once in early morning before anyone is here and once > > at lunch. The morning build runs fine (I would guess this is because > > no ones use the application for hours so IIS has released its file > > locks) but the afternoon builds during lunch forces a reboot most of > > the time (I would guess because IIS has file locks due to recent > > activity), which is not only annoying because its rebooting the > > server, but also the server hosts other software (such as virtual > > servers) taking that down. I have tried stopping IIS before it > > begins the install but it still causes a reboot most of the time. Is > > there a switch that could solve this or some way to make windows > > locking more > sane or something? I am just stumped. > > > > Thanks in advance, > > Adam. > > -------------------------------------------------------------------- > > -- > > -------- > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > -------------------------------------------------------------------- > > -- > > -------- > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > ---------------------------------------------------------------------- > -- > ------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------ ------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
