I have a burn bundle that includes a perUser package and perMachine package. The perMachine package adds just one firewall exception that requires UAC.
I understand that UAC is required when the firewall exception is added on initial installation, but why is it required on a Major Upgrade if the only components that have changed are in the perUser package? Why doesn't the installation recognise that the perMachine component is already installed and just skip over it with no UAC?
I've tried changing MajorUpgrade to Schedule="afterInstallExecute" but this has no effect on the UAC.
A per-machine package requires elevation. Major-upgrade packages can be completely different from each other, so MSI doesn't break it down to the level of individual components requiring upgrade. If you want to avoid another UAC prompt, you can use UAC patching.
Related
I am using WixStandardBootstrapperApplication to chain the install of .Net framework followed by my standard MSI package. My MSI package needs to identify the invoking user to write to the %USERPROFILE% location, however Burn requests privilege elevation from the start and runs my entire MSI under the elevated context. My MSI package worked correctly before being bundled in the bootstrapper - in that it only elevated after the InstallUISequence. Is there a way around this?
Burn installs all the per-machine packages in a chain from a single elevated process. Likewise, per-user packages are installed from a single unelevated process. There's no option to change that behavior.
i am trying to Upgrade MSI from Per-Machine to Per-User.. but its not working.
After Upgrade it shows twice on Control panel and twice shortcut on the desktop means its unable to uninstall pervious one.
and it able to Upgrade Per-Machine to Per-machine and Per-User to Per-User but unable to upgrade Per-Machine to Per-user
New Build Code
OLD BUILD CODE
This is because the major upgrade does not work across installation contexts (what WiX calls installScope). Thus the previous version is not being uninstalled. The second note on Major Upgrades says this:
Note If an application is installed in the per-user installation context, any major upgrade to the application must also be performed using the per-user context. If an application is installed in the per-machine installation context, any major upgrade to the application must also be performed using the per-machine context. The Windows Installer will not install major upgrades across installation context.
My Requirements:
I have few MSI files which need to be installed. User can select which one he wants to install/uninstall. For this purpose I have used WiX bootstrapper where I have used WPF UI to list down all the MSI and few buttons to Intstall/Upgrade/Uninstall
Till now I am able to install selected MSI using InstallCondition but could not manage the uninstall. If I uninstall any of the MSI, the Bundle is also getting uninstalled. Hence it is not showing in the Add/Remove Program.
So I would like to know if there is any way to allow uninstall of individual MSI but not the Bundle itself?
I'm guessing your bundle is getting uninstalled because you are using Engine.Plan(LaunchAction.Uninstall). If you use a different action like Install or Modify, it shouldn't be removed.
To control the install state of the individual MSI packages, I think you can set that in a callback to PlanPackageBegin.
I have a custom installer based on WiX technology which is install several .vsix packages into Visual Studio.
If this packages are already installed, the installer offers to remove them. After the removal process is completed, the installer exits.
It's normal behaviour, but I need to offer the user re-install this packages (optionally) before exit. I mean optional mode to uninstall the previous version and install the new one (or the same) with a single run of the installer.
How to implement this in WiX ?
I suspect your custom installer could be made a little smarter. There are plenty of APIs (such as MsiQueryProductState) that will tell you if that exact ProductCode is installed, and ways to get the version (MsiGetProductInfo). My guess is that your custom installer is just firing off all the MSI installs without checking if they are already installed, hence the Remove prompts.
Your general plan should be to have some data available to your custom installer that it can use to find out what's already installed and what the versions are, and then compare these with what you are about to install. Use those APIs. If the product is already installed then skip the install. If you have a newer version (that you built with the WiX MajorUpgrade element) then just install it because it will replace the existing older one.
There's nothing I can think of in WiX that would automatically reinstall a product that your custom installer caused removal of by re-installing it and prompting the user to remove it, if that's what's going on.
I have a Wix project that I have set to allow major upgrades. I'm using WixUI_Advanced for a choice between per-user and per-machine installs. When I install and upgrade per-user everything works as expected, the installer recognizes an upgrade and there is only one entry in Programs and Features. However when I choose a per-machine install, it starts duplicating entries in Programs and Features (even when both install and upgrade are per-machine and to the same folder).
Looking at the install log file it seems that FindRelatedProducts is executing before the user gets a chance to select a per-machine install, so the installer thinks that the context has changed and won't do an upgrade. I attempted to suppress FindRelatedProducts in InstallUISequence but when I do that the installer still skips FindRelatedProducts in the InstallExecuteSequence.
What are my options at this point?
You could manually execute the FindRelatedProducts action again, after the installation context was selected. Use the MsiDoAction method. I used this approach once and it seemed to work.
A better approach would be to run your own custom action before FindRelatedProducts that would search for a previous version of the product already installed. That custom action should set ALLUSERS to either 1 or to Nothing depending on the scope of that previous version, so that FindRelatedProducts finds it and schedules its upgrade. A good idea would then be to disallow selecting the per-user scope for the user if the previous version was installed per-machine - otherwise the installer may have insufficient privileges to upgrade the previous per-machine installation.
This seems to be the approach taken by InstallShield. If you create an empty test MSI package with the free InstallShield Limited Edition and then de-compile it with Dark, you will see that that custom action is called IsSetAllUsers and located in SetAllUsers.dll.