[wix-devs] Reinstalling Bundle packages
bob at firegiant.com
Tue Jan 4 14:25:25 PST 2022
BOOTSTRAPPER_REQUEST_STATE_FORCE_PRESENT, a la BOOTSTRAPPER_REQUEST_STATE_FORCE_ABSENT?
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Tuesday, 4 January, 2022 16:01
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Sean Hall <r.sean.hall at gmail.com>
Subject: [wix-devs] Reinstalling Bundle packages
If you look at my PR for related bundles as BundlePackages in Burn, at
there's a special fPseudoBundle flag to allow installing even if the bundle is already detected as present (this was in exeengine.cpp in v3). I want to get rid of the fPseudoBundle flag so that related bundles will work the same as BundlePackages when that's added to the language.
Also, for 3421 I'm trying to figure out how to let the BA control the behavior for upgrade bundles when it is rolling back. For example, maybe the BA wants to opt out of rerunning the upgrade bundles or it wants to do a repair instead of install. Again, we need to expose the ability for a BA to request to install the bundle even though it's already present.
I'm considering adding BOOTSTRAPPER_REQUEST_STATE_REINSTALL, but I don't like that for the same reasons I didn't like
* There won't be an overall action BOOTSTRAPPER_ACTION_REINSTALL
* BOOTSTRAPPER_REQUEST_STATE_REINSTALL can't be requested for MSI/MSP/MSU packages
For 3421, I would add a new requested state for the restore operation. I guess another option would be a simple boolean flag like fDisableRestore, and the BA wouldn't get to ask for repair.
Does anyone have any other ideas?
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/
More information about the wix-devs