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-and-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
