Tomasz Chmielewski schrieb: > Rainer Meier schrieb: > > (...) > >> It's an ugly work-around trying to kill applications which are currently >> running just to unlock these files. Especially since you never know >> which other applications (indexing serivice, 3rd party tools...) open >> the same file. So replacing a file might fail at any time. I think >> that's exactly the reason why an installer can queue such changes in >> order to be executed at next reboot. > > Yeah, I too hope there is some way to do it within the MSI. > > Writing another application which just handles updates doesn't seem to > be a very good idea for me... I asked some Microsoft MVPs and it doesn't look too promising: 1) Most (all?) installers do an upgrade by stopping the service first 2) Vista SP1 will include 'hotpatching, a reboot-reduction servicing technology designed to maximize uptime. It works by allowing Windows components to be updated (or "patched") while they are still in use by a running process'. Wow, what a cool name for something obvious in UNIX world ;) 3) There is no magic MSI switch or hack to perform an upgrade automagically next time the machine is started Unfortunately, this doesn't give us much choice: - there is a switch/hack, but we don't know it yet - for WPKG Client, we need to write another application (service?) which just upgrades WPKG Client - short term: it should be enough to write a script which waits with starting msiexec until WPKG logon is gone Long term: make it integrated better / more automatic / easier etc. -- Tomasz Chmielewski http://wpkg.org |