> 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
