>From the behavior listed, it would appear to me that the old MSI has a
ResolveSource action AND that they use their bootstrapper to ensure that the
"source" is available to successfully uninstall.
The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\
registry key supports two kinds of entries: "legacy" and "msi". The MSI ones
always have a guid as the key name inside of the Uninstall key. Thus,
"MyApplication" would be a "legacy" type entry.
Legacy type entries have working UninstallString values (assuming that you
can remove successfully from ARP), while the UninstallString value for msi
type entries are ignored by ARP (but by default have a functional value).
You will likely need to create a custom action that will call the
uninstaller. You can easily distinguish the previous versions from your
newer builds using an additional entry in the upgrade table since you know
the highest version number you released using the previous toolset.
<Upgrade Id="$(var.UpgradeCode)">
<UpgradeVersion Minimum="$(var.ProductVersion)" OnlyDetect="yes"
Property="NEWERVERSIONDETECTED" />
<UpgradeVersion Minimum="1.0.0" IncludeMinimum="yes"
Maximum="3.70" IncludeMaximum="yes" OnlyDetect="yes"
Property="OBSOLETEVERSIONBEINGUPGRADED" />
<UpgradeVersion Minimum="3.70" IncludeMinimum="no"
Maximum="$(var.ProductVersion)" IncludeMaximum="no"
Property="OLDERVERSIONBEINGUPGRADED" />
</Upgrade>
Here you have two alternatives:
1. Create a custom action conditioned on OBSOLETEVERSIONBEINGUPGRADED that
runs the uninstallation of the previous product in your UI sequence (since
it will fail if you include it in your execute sequence). I would recommend
placing it before the ExecuteAction action.
2. Create a custom action conditioned on OBSOLETEVERSIONBEINGUPGRADED that
extracts the MSI from the EXE from the previous product in your execute
sequence and adds the directory it places that file into the source list of
the ProductCode identified in the OBSOLETEVERSIONBEINGUPGRADED variable.
Then remove the OnlyDetect attribute from the UpgradeVersion element that
creates the OBSOLETEVERSIONBEINGUPGRADED property.
The second is more work but will allow you to remove the previous version
more reliably and as part of your installation transaction (meaning you have
rollback, etc.).
-----Original Message-----
From: Dave Mateer [mailto:dave_mat...@ntm.org]
Sent: Thursday, January 28, 2010 12:16 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Remove works in Control Panel, fails in Wix (or
msiexec)
OK, I think I know the answer to this before I ask, but I'm earnestly hoping
that this is not a dead-end. Here's the situation:
We're moving from InstallAware to WiX. We have an application installed from
an InstallAware-generated EXE and MSI. If you go to Add/Remove Programs and
remove it, it works fine. However, if you try to remove it using the
<RemoveExistingProducts> action in Wix, or directly with msiexec /x, it
fails with:
> The feature you are trying to use is on a network resource that is
unavailable.
> Click OK to try again, or enter an alternate path to a folder containing
the installation package 'MyApplicationSetup.msi' in the box below.
> Use source: [C:\Users\Admin\AppData\Local\Temp\mia1] [Browse...]
> [OK] [Cancel]
When you click cancel, it displays:
> An installation package for the product MyApplication cannot be found. Try
the installation again using a valid copy of the installation package
'MyApplicationSetup.msi'.
> [OK]
If I look in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\MyApp
lication, the UninstallString does NOT have the normal MsiExec.exe /X{...},
but rather: "C:\ProgramData\{SOME-BIG-GUID}\MyApplicationSetup.exe"
REMOVE=TRUE MODIFY=FALSE". {SOME-BIG-GUID} is different on each install.
I'm guessing that this means the EXE is doing some magic before passing
control to the Windows Installer engine.
So, has anyone run across this before? I suppose we could have a custom
action that looks up the registry key and runs the old
MyApplicationSetup.exe with the magic parameters. But I'm wondering: do we
then have to support this hack in every version until there's little chance
of anyone having the old InstallAware-generated application? Ugh.
Is there a WiX way of handling this gracefully?
Thanks,
Dave
----------------------------------------------------------------------------
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the
business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
