Just to put a close to this thread (in case anyone stumbles upon it in the future), we now have a separate updater service from the main client service, and they can now successfully upgrade each other. So I consider the matter closed, since we circumvented the problem.
One strange observation is that, during development and testing, I think I saw the updater successfully upgrade ITSELF (which it isn't supposed to do, and which I assumed would fail if it tried), which the main client was not able to do (which is the whole reason we split the updater). However, time is/was of the essence, so I didn't investigate why the updater (which is much lighterweight, but still written in Java) might have been able to upgrade itself, and the client was unable to do so for itself. In any case, all's well that ends well. Thanks for all your help! Alain -----Original Message----- From: Blair Murri [mailto:os...@live.com] Sent: July 3, 2013 20:09 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrade uninstall restart issue 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-executio > > n- > > 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/Upgrad > > e- 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 ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
