Well another poster pointed out COM which I "forgot" (/wishfully forgot :-) ) existed. Due to how we develop our COM, and some might say the stubbornness not to change it (which I can sorta understand, it works so why change it), I am having to manage the COM via custom actions, so if a COM application is active during lock checks then that's probably locking the DLLs. Since I think COM by default doesn't unload a component (or application, one of them I am sure) from active memory till its not been used for 2 or 3 minute the VB6 COM DLLs are going to be locked. Unfortunately I can't confirm this till I am back in work so, we'll soon see ... I say soon we are talking 10 hours minimum, but that's soon in the grand scheme of things :-P.
Cheers, Adam On Wednesday 21 January 2009 23:18:56 Chad Petersen wrote: > We have a large web site, too. With many services running beside IIS. > Any time we get locks I take a verbose log and search for "in use" and > it always tells me the process that has the file in use and I can make > some correction to take care of it. Never been a problem that could be > handled so far. > > -----Original Message----- > From: Adam Burton [mailto:adz...@googlemail.com] > Sent: Wednesday, January 21, 2009 2:28 PM > 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
