HandleObsolete needs to be anywhere convenient before RemoveExistingProducts. Before InstallInitialize is fine.
-----Original Message----- From: Dave Mateer [mailto:dave_mat...@ntm.org] Sent: Friday, January 29, 2010 8:56 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Remove works in Control Panel, fails in Wix (or msiexec) Nevermind on the first question. I had a "duh" moment as soon as I hit send. Using: [DllImport("Msi.DLL")] [return: MarshalAs(UnmanagedType.U4)] internal static extern int MsiSourceListAddSource(string szProduct, string szUserName, [MarshalAs(UnmanagedType.U4)] int dwReserved, string szSource); Still curious about second question, though. -----Original Message----- From: Dave Mateer Sent: Friday, January 29, 2010 11:42 AM To: 'wix-users@lists.sourceforge.net' Subject: RE: Remove works in Control Panel, fails in Wix (or msiexec) Thanks, Blair. You are a treasure of information, and I really appreciate your help! I've gotten this far: - I have created stub custom action and put the conditions on it. By looking at the log, that is all working fine. - I can get the directory. - I have the value of OBSOLETEVERSIONBEINGUPGRADED Question #1: I need help at: "adds the directory it places that file into the source list of the ProductCode identified in the OBSOLETEVERSIONBEINGUPGRADED variable." I assume means using MsiSourceListAddSource? Can that be called from a managed (C#) custom action? (Yes, I'm a managed code wuss and would REALLY like to avoid the C++ if possible; we already depend on the .Net framework so that's no problem.) Question #2: I'm not confident I'm sequencing these correctly. RemoveExistingProducts must be called after my custom action. Should I use: | Custom HandleObsolete | RemoveExistingProducts | |---------------------------|-------------------------| | Before InstallInitialize | After InstallInitialize | | After InstallInitialize | After HandleObsolete | (generates warning ICE63) | After InstallInitialize | After InstallExecute | Or something else? Dave ---------------------------------------------------------------------- From: "Blair" <os...@live.com> Subject: Re: [WiX-users] Remove works in Control Panel, fails in Wix (or msiexec) <snip /> Here you have two alternatives: <snip /> 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
