Have you tried an exe that launches the updater and then immediately exits (without waiting for the updater to exit)? I'm curious if that would change any of this dynamic. > From: afor...@cmu.edu > To: os...@live.com > Subject: RE: [WiX-users] Upgrade uninstall restart issue > Date: Wed, 3 Jul 2013 14:59:02 -0400 > > Curious that there's no baked-in dependency, because every time I try to > upgrade the software myself (rather than having our client upgrade itself), > it works fine without any request to restart, and hence no problem. This is > true whether I run the upgrade's installer myself, or if I have a process > external to my service download and run the upgrade. Because my services are > Java-based, maybe there's some combination of the service architecture and > how Java spawns new processes that creates some kind of dependency. > > Thanks also for the Process Monitor advice. I'm pretty convinced that there's > some kind of dependency-loop going on, so I'm now looking into having another > process or service other than our main client perform the update. > > So I'm envisioning a second MSI package for an updater service, so that its > version doesn't increment (and then get "upgraded", causing the same problem) > when our main client's software needs to be upgraded. > > But then, what if I one day need to upgrade the updater? The only way I think > this can be done is to ask the user to run the new version's installer > themselves. I can't have the main client update the updater, because what if > it's been a while since an update has been done at all and the Bundle > contains BOTH a client upgrade and an updater upgrade? Then no matter which > service does the upgrade, I'll have the same dependency loop problem. So I > guess the user will have to do it, but I can't imagine why we'd ever what to > upgrade the updater, so if it does happen, it probably won't be very frequent. > > Unless you know of a third option? > > Alain > > -----Original Message----- > From: Blair Murri [mailto:os...@live.com] > Sent: July 3, 2013 04:50 > To: afor...@cmu.edu > Subject: RE: [WiX-users] Upgrade uninstall restart issue > > There is no such dependency "baked-in" to the system. The only tracking is > the parent process's ID is in placed in the child's process information > structure at the child's launch. When a process ends, all handles assigned to > that process are automatically closed and children are not given any handle > to their parents (unless the parent explicitly prepared and sent them one). > Also, while the service control manager tracks the processes hosting each > service, it does not track subprocesses. The only other overall "tracking" of > note is when the system stops all processes associated with any given profile > being unloaded (whether some user account being logged out or the entire > system is shutting down). > > WRT process monitor: first filter on all accesses/handles to the files you > are replacing in your upgrade, looking to see especially what process(es) > still have what file(s) open when Windows Installer is renaming/moving them > in preparation to write out the newer version of them (it won't actually > throw the flag to prompt for reboot until it is unable to delete those > renamed copies, but all holders of those files should have already closed > their handles due to exiting before the attempt to overwrite). > > The majority of cases I've seen of this in the field have been anti-virus > software locks, but that doesn't exclude something else... > > Blair > > > > From: afor...@cmu.edu > > To: r...@robmensching.com; wix-users@lists.sourceforge.net > > Date: Tue, 2 Jul 2013 15:04:21 -0400 > > Subject: Re: [WiX-users] Upgrade uninstall restart issue > > > > I don't know the Windows process & service model as well as I probably > > should, but my hypothesis regarding my problem is that the package > > installer cannot stop MyClient service, because MyClient service spawned > > the bundle installer, which in turn spawned the package installer which is > > trying to stop MyClient service. > > > > I'm guessing this causes an unresolvable loop because there's some kind of > > dependency whereby the MyClient service won't fully stop until its children > > processes have terminated, even though MyClient's execution does not > > actually dependent on those processes at all (and I in fact WANT it to > > stop/terminate, and it is coded as such, as far as I know). > > > > To those of you who understand processes and services better than I, does > > this make sense? Or is there no such parent-child dependency amongst > > processes/services? > > > > Alain > > > > -----Original Message----- > > From: Alain Forget [mailto:afor...@cmu.edu] > > Sent: July 1, 2013 18:20 > > To: 'Rob Mensching'; 'General discussion for Windows Installer XML toolset.' > > Subject: RE: [WiX-users] Upgrade uninstall restart issue > > > > > Burn is very self-contained and only uses files it carries with it, > > > although a custom BA can do anything. > > > > I'm not using any custom BA (that I know of). My Bundle source is below > > this message, for your reference. Please let me know if you see anything > > wrong (or don't see something that should be there). > > > > > If you haven't already, I'd recommend using Process Monitor to see if > > > what locks your files when they are trying to be removed. > > > > I've been wrestling with the Process Monitor logs and, having never used it > > before now, I can't make sense of the jungle of activity. Do you have any > > suggestions on what exactly I should be looking for? > > > > > Note: Burn will not install or uninstall packages that are not explicitly > > > listed in the Chain today. However, a package in your chain may upgrade > > > an existing package on the machine during install. > > > > Yes, that is what I would expect, so I'm not sure how that might be a bad > > thing in my case. > > > > > Note2: Very screwy that a package would be detected per-user when it is > > > really per-machine. That would be something to investigate further. > > > > Good to know that's not something to ignore, but I have no idea how to > > investigate further. As I said, in our Package, we have set > > InstallScope='perMachine' and even tried adding > > InstallPrivileges='elevated', as well as ForcePerMachine="yes" to the > > MsiPackage element in the Bundle's Chain, but somehow it still seems to > > think the package was installed per user, when it definitely should not be. > > So how could this be further investigated? > > > > Finally, as promised, our Bundle's WiX source: > > > > <?xml version='1.0' encoding='windows-1252'?> <Wix > > xmlns='http://schemas.microsoft.com/wix/2006/wi' > > xmlns:bal="http://schemas.microsoft.com/wix/BalExtension"; > > xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"; > > > > > > > <?ifndef PRODUCTVERSION?> > > <?error PRODUCTVERSION must be defined ?> <?endif ?> > > > > <Bundle > > Name="My Client v$(var.PRODUCTVERSION) Installer" > > UpgradeCode="MYUPGRADEGUID" > > Version="$(var.PRODUCTVERSION)" > > Copyright="Copyright © Us. All rights reserved." > > IconSourceFile="lib/Icon.ico" > > Manufacturer="Us" > > DisableModify="yes" > > HelpUrl="mailto:u...@us.com"; > > > > > <BootstrapperApplicationRef > > Id="WixStandardBootstrapperApplication.RtfLicense" > > > <bal:WixStandardBootstrapperApplication > > LicenseFile="License.rtf" > > LogoFile="lib\logo.png" > > SuppressOptionsUI="yes" > > ThemeFile="MyRtfTheme.xml" > > /> > > </BootstrapperApplicationRef> > > > > <!-- Abort installation if not running with administrator privileges > > --> <bal:Condition Message="This installer requires administrator > > privileges to run."> Privileged <!--OR AdminUser--> </bal:Condition> > > > > <!-- Abort installation if not running on Windows 7 or 8 --> > > <bal:Condition Message='Sorry, but this software only supports Windows > > 7 or Windows 8.'> VersionNT >= v6.1 AND v7.0 > VersionNT > > </bal:Condition> > > > > <Chain DisableSystemRestore="yes"> > > <PackageGroupRef Id="pkgJRE7" /> > > <MsiPackage > > Id="pkgMyClient" > > DisplayName="My Client" > > Cache="no" > > Compressed="yes" > > ForcePerMachine="yes" > > Permanent="no" > > SourceFile="MyClientPackage_v$(var.PRODUCTVERSION).msi" > > Visible="no" > > Vital="yes" > > ></MsiPackage> > > </Chain> > > </Bundle> > > </Wix> > > > > -----Original Message----- > > From: Rob Mensching [mailto:r...@robmensching.com] > > Sent: July 1, 2013 01:28 > > To: afor...@cmu.edu; General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Upgrade uninstall restart issue > > > > I don't know what in Burn would lock existing files. Burn is very > > self-contained and only uses files it carries with it, although a custom BA > > can do anything. If you haven't already, I'd recommend using Process > > Monitor to see if what locks your files when they are trying to be removed. > > I'd be very surprised if it was anything in the Burn process. > > > > The order you are seeing in Burn is expected. There are some details > > here: > > https://support.firegiant.com/entries/24024208-Bundle-chain-execution- > > order- > > > > Note: Burn will not install or uninstall packages that are not explicitly > > listed in the Chain today. However, a package in your chain may upgrade an > > existing package on the machine during install. > > > > Note2: Very screwy that a package would be detected per-user when it is > > really per-machine. That would be something to investigate further. > > > > > > > > On Sun, Jun 30, 2013 at 7:43 PM, Alain Forget <afor...@cmu.edu> wrote: > > > > > > I know about those, but how do I use them to prevent Burn from locking the > > existing files before it runs the installer package to MajorUpgrade? > > > > > > -----Original Message----- > > From: Phill Hogland [mailto:phogl...@rimage.com] > > Sent: June 30, 2013 20:54 > > To: wix-users@lists.sourceforge.net > > Subject: Re: [WiX-users] Upgrade uninstall restart issue > > > > > > Maybe this blog would be helpful: > > http://code.dblock.org/msi-property-patterns-upgrading-firstinstall-an > > d-maintenance > > > > > > > > > > -- > > View this message in context: > > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrade- > > uninstall-restart-issue-tp7586315p7587020.html > > Sent from the wix-users mailing list archive at Nabble.com. > > > > ---------------------------------------------------------------------- > > -------- This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > ---------------------------------------------------------------------- > > -------- > > > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > -------- This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows:
Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
