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.
Related
I have an msi bundled with prerequisites using Wix bootstrapper (burn.exe).
We migrated this project from Installshield to WiX.
The installation works fine.
However, during repair or uninstall the bootstrapper runs the msi-file in silent mode.
Since the last dialog (e.g. 'SetupCompleteSuccess') within the msi file contains some controls to trigger some more actions.
Is there a possibility to configure the bootstrapper so that the msi file is executed in 'UI'-mode?
In WiX v3, it is not possible. Burn explicitly shows internal UI only during initial install. WiX v4 changes how that works: https://github.com/wixtoolset/issues/issues/5616
I created an MSI with WIX that needs elevated permissions to work correctly. In the MSI Project, I specified this via
<Package [...] InstallPrivileges="elevated" />
Now I included this MSI in a custom bootsrapper project, based on WixWPF Bootstrapper.
As I understand it, the bootstrapper itself should not alter the machine state and thus should not require elevated privileges.
I would now expect the Bootstrapper to automatically launch the integrated MSI with elevated priviliges, prompting the user with a UAC dialog, if necessary. But it does not. Instead, the installation just fails.
It works however, when I run the bootstrapper executable explicitly as administrator.
How do I make the bootstrapper ask for elevated permissions when installing the MSI?
Since the INSTALLSCOPE attribute for the MSI was not set, it defaulted to Per-User install and the bootstrapper application considered that it does not need any ADMIN/Elevated rights to run it.
Now in your case, you are the author of the MSI and it was easy enough for you to add the InstallScope to the package element.
InstallScope="perMachine"
If you are not the author of the MSI, still bootstrapper provides a property which you can use to force the per-machine for the MSI/EXE.
MSIPackage - ForcePerMachine
EXEPackage - PerMachine
So why does Bootstrapper think that Per-Machine install needs elevated privileges and Per-User doesnt? Simple enough, per-user installation the registry value is written under HKEY_CURRENT_USER and for Per-machine installation the registry value is written under HKEY_LOCAL_MACHINE. Only Admin users can read/write to HKLM.
I have created a Wix Burn app that I am installing two MSI's with. Works great.
The MSI files install properly
The Wix Burn app registers with ARP.
The MSI files do not register with ARP
I can do Major Upgrades
I can install and uninstall manually with a local copy of the Wix Burn app
I can programmatically execute the Wix Burn app to uninstall (using /x)
The Problem:
I know two way to uninstall using a Wix Burn app:
Click on the Uninstall button in ARP (requires user involvement)
Launch a copy of the Wix Burn app that installed the product
I see in the Wix Burn log that Windows caches my Wix Burn app install in much the same way that MSIEXEC will cache MSI files. Is there a way to programmatically ask Windows or MSI to use the cached version of the Wix Burn app to do the uninstall?
A Possibility:
Presumably I could use MsiGetProductInfo() to get a path to the cached Wix Burn app. To do that, however, I need my app's Product Code. However, Product Codes are not attributes of elements in Wix so I am not seeing how to get a Product Code for a Burn package.
You might be able to solve this by iterating through the Uninstall registry entries. The process is:
Open HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.
Iterate through the sub-keys searching for an entry where the Publisher and DisplayName matches your product.
If you find an entry, read the value of QuietUninstallString and run that as a command. For a WIX burn installer this is typically in the form C:\ProgramData\Package Cache\{GUID}\SetupProgram.exe /uninstall /quiet.
If you are using a 64 bit operating system you will also need to search HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall.
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.
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.