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.
Related
I have a bundle which installs two products: the application and a much larger resources installation.
For upgrades the application msi will apply a standard upgrade, but the resources installation gets patched instead. (Unfortunately this process started a while ago, so the patch chain is still built using Wix 3.0).
On uninstall of the bundle the application is fully and correctly uninstalled, but the patch only is removed, leaving the full install of whatever previous version of the resources existed (downgrade from 1.5.0.0 to 1.4.0.0).
Is there a method to force a full uninstall of the full product, rather than just the .msp patch, through the bundle?
Edit: Just to add, exposing the resources installation in Programs and Features and running an uninstall there will remove the entire product correctly as expected.
I think this could be a possible solution for you.
I just tested myself a very simple bundle with one MSI in it. What I did was have the main bootstrapper installer have the msi embedded in it an install it. The second bundle had a higher version and the exact same msi reference but I set compressed="no" in the <MsiPackage> tag. When I uninstalled the upgraded bundle it also removed the original MSI.
So I think you can get your bundle to properly remove the original "Resources" installation after you've upgraded and added a small msp. You just need to add back the <MsiPackage> to the bundle chain before the msp and set compressed="no"
<MsiPackage SourceFile="$(var.ResourcesInstaller.TargetPath)" Compressed="no"/>
The only caveat here is that the SourceFile should be the exact same msi that was included in your first install. When you install the upgrade, the burn engine should detect this msi as already installed so nothing would be needed to be done. When uninstalling, it will detect the msi as installed and should uninstall it.
I'm not completely sure this will work but it is something to try. Another nice thing about this is it will have virtually no impact on the size of your upgrade installers.
I'm using WIX to create a new installer for an existing product. The installer is very simple - just drops a few dll's into a specified folder on disk.
In the field, my users already have that folder with old dll's in them (since they installed the old MSI - created using a *.vdproj project in VS).
My problem is that after I install the WIX, I have both the old MSI and the new Wix MSI appear in Add/Remove. Expected (? since these 2 are two different kind of MSI's?). I need some kind of an upgrade mechanism - so I was wondering if I can call the old MSI uninstaller from within the WIX one. Or alternately somehow take care of the old Add/Remove entry (a registry hack perhaps?)
Assuming the old install and the new install are installed using the same context ( per-user -> per-user or per-machine -> per-machine ) you can use a MajorUpgrade rule to find the old version and get rid of it. You can do this by syncing up the UpgradeCode property and using a higher ProductVersion or you can do it by authoring a second Upgrade rule using the legacy UpgradeCode GUID.
If the old install was per-user and you want the new install to be per-machine you are out of luck. This isn't supported by MSI. Typically I only support per-machine installs and hardcode the ALLUSERS property and remove the CustomerInformation dialog from the installer UI experience. This is not the default experience for VDPROJ based installers.
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 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.