I have two bundles. Both bundles contain 2 msis. One of these msis is shared between bundles so we have something like that:
Bundle1 contains Product1.msi and Aux.msi
Bundle2 contains Product2.msi and Aux.msi
As you can see Aux.msi is part of both bundles.
When I install both bundles on one PC everything is file. For the second bundle bootstrapper sees that Aux.msi is already installed, skips install operation for it, and marks in registry dependencies so that Aux.msi gets uninstalled only when both bundles are removed.
But when Bundle2 has Aux.msi of the newer version here comes the problem. Here is the order of operations:
Install Bundle1 which contains Product1.msi (version doesn't matter) and Aux.msi (version 1.0.0) - everything is ok
Install Bundle2 which contains Product2.msi (version doesn't matter) and Aux.msi (version 2.0.0) - bundle catches that the previous version of Aux.msi is installed, uninstalls version 1.0.0, installs version 2.0.0. Everything looks good here but in the registry Bundle2 is set to the dependencies of Aux.msi and Bundle1 is left with the dead dependency to the Aux.msi of version 1.0.0. That is why if afterwords I uninstall Bundle2 the Aux.msi is uninstalled too and I get a broken installation of Bundle1 without Aux.msi on the PC.
I truly believed that these kinds of situations should be handled properly by the burn engine. Any ideas on how to fix it?
To enable ref-counting across upgrades, declare the dependency provider in Aux.msi:
<!-- a pre-existing component that is always installed -->
<Component>
<dep:Provides Key="AuxKey" />
</Component>
This assumes that all upgrades of Aux.msi are backwards compatible. The Provides/#Key and probably the MSI's upgrade code will need to change when that isn't true.
Related
I have a Application that is to be installed by two different MSI installers, INSTALLER1 and INSTALLER2.
So can this achieved by keeping same GUID and PATHs.
Use case 1. APPLICATION installed by INSTALLER1 and after some time uninstalled by INSTALLER2, will it notify to INSTALLER1 that it has been uninstalled?
2. APPLICATION installed by INSTALLER1 and after some time upgraded by INSTALLER2, will it notify to INSTALLER1?
Or do need to check other things such as Upgrade code, package code, Component ID should be same( in addition to GUID)
Any pointers will be helpful
I found another post, that I think is your post as well.
Can a single component installed by two different installers, if we keep same GUIDs and Paths for files,services, registries, upgrade codes?
You are using the term 'product' in a confusing manner.
In your other post you reference merge modules, these are a collection of files arranged in components. Your merge module will be consumed by another installation package. There is NO upgrade code for a merge module, there is no package code, or product code either.
If I am understanding your question, if you have configured your components correctly in the merge module, then the component rules will take effect no matter how many products install your application. There is no 'notification' needed.
So, let's say you create your merge module, and the files install to C:\Program Files\MyGreatApp.
MSI_1 and MSI_2 consume your Merge Module 1.0.0.
A customer installs MSI_2, at this time your component information is written to the registry and indicates that MyGreatApp component is version 1.0.0
Later the customer installs MSI_1, at this time when it installs, it notices that MyGreatApp component is already installed and is version 1.0.0, the component will not install at this time because it already exists on the system.
Let's say you release MyGreatApp v2.0.0 and MSI_2 consumes this merge module.
If a customer installs MSI_1, then MyGreatApp v1.0.0 is installed
If a customer later installs MSI_2, the install sees that the component is installed, but the version is 1.0.0, so based on component rules, it has a newer version.
So, from an installer issue, this should honor component rules.
The question you have to ask is that when your app is upgraded from v1.0.0 to v2.0.0, will that cause a break in the code. If your files are compiled separately from the main MSI you should be all set, however, if your files are used as references in the primary application, and this is a .NET assembly that uses strong name key file, you will get dependency not found errors.
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.
We have two WiX installers that use our own BA. One installer gets all the packages from the web, while the other gets all the packages from the exe. We call them "Web" and "Full" installers.
We have a case where a user might install one package from the web installer and a different package form the full installer. It probably won't happen often but it could happen. When the user does this, we have two entries in the Add/Remove programs control panel. Since we didn't name the installers differently, it looks like the installer is installed twice.
My question is, if the only difference between two installers created with WiX is the way the packages were acquired, shouldn't it just appear once in Add/Remove programs? Do I need to set a code somewhere to say it is the same installer?
I guess we could just name them differently so that a "Web" and a "Full" installer appeared in Add/Remove Programs, but when you run either one, both packages show up for uninstallation because both installers know about them. It's not like the web installer only shows the package that was installed through it and the full the package that was installed through it.
Any comments are appreciated.
In a version upgrade scenario, using the same UpgradeCode for both <Bundle...> packages is enough to indicate both installers are the same product. For example, if you first install package V1.0 and later install package V1.1 (where both packages use the same upgrade code) Package V1.1 replaces Package V1.0 in Add/Remove Programs.
Unfortunately the burn engine does not support same version upgrades. If you have different packages with the same upgrade code and the same version, both packages will appear in Add/Remove Programs. For more information on burn not supporting same version upgrades see: http://wixtoolset.org/issues/3746/.
Installing two different packages with the same upgrade code and version is well behaved. For example, if you install both packages and subsequently remove one of them, the resources in the first package remain installed, even though the same resources are also in the second package.
Installing two different packages with the same upgrade code and version, then later installing a third package with the same upgrade code but a higher version is also well behaved. The third package replaces the first two packages!
Your suggestion of varying the name of the packages to differentiate them in Add/Remove Programs sounds the most pragmatic way forward. Having two entries does not appear to compromise the installation state, and upgrades appear to be handled without issues.
I am a great fan of continuous integration, deployment and delivery. I believe that revision based upgrades is way to go here but it seems like using WIX based installers makes it really hard to support this feature. I am currently trying to change installer of our product so that it can be installed side-by-side (multi instance support) and allow revision based upgrades. In my case I want to allow installation of 1.0.0.0 and 1.0.0.1 version of product side by side and also support upgrade any of installation like just allowing upgrading from 1.0.0.1 to 1.0.0.2 without changing 1.0.0.0 version of product.
So in given scenario,
When installing 1.0.0.1 on top of 1.0.0.0, then 1.0.0.0 needs to be upgraded.
When installing 1.0.0.1 as new instances, then both 1.0.0.0 and 1.0.0.1 needs to be co-exist on same box (Installation will use different location). It should installed like a new one and display in Add/Remove program twice.
In future 1.0.0.2 should be able to upgrade any one existing instance (1.0.0.0 or 1.0.0.1) without changing other instances.
Installing 1.0.0.1 on 1.0.0.1 should perform usual repair.
Installer should prevent downgrade.
I tried Wix MajorUpgrade element but it didn't work the way i wanted. Here is complete result of my experiment.
1. Install 1.0.0.0 then upgrade to 1.0.0.1. It works well (as expected)
2. Install 1.0.0.1 as new instance then both 1.0.0.0 and 1.0.0.1 co-exist on same box (Works).
3. Install 1.0.0.2 as upgrade to 1.0.0.0 (not 1.0.0.1). Here is problem. It uninstalls everything (both 1.0.0.0 and 1.0.0.1) and didn't installed 1.0.0.2 properly.
Last result was really weird and i am not sure how to make that work where installation should upgraded target version only without uninstalling all instances ? Any help or guidance will be really appreciated.
<Product Id="*"
Name="$(var.ProductName)"
Language="1033"
Version="$(var.Version)"
Manufacturer="$(var.Manufacturer)"
UpgradeCode="MY-UPGRADE-CODE">
<MajorUpgrade Schedule="afterInstallInitialize" DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit." />
You'll need to stop using the MajorUpgrade element and build version specific upgrades. MajorUpgrade is basically a short and sweet way to get every prior version upgraded. Instead, you need to build specific WiX Upgrade elements that target the specific version range you want to upgrade. Your 1.0.0.2 would have an Upgrade element that targets only version 1.0.0.0 for the upgrade.
Can't say much about the failed upgrade without more detail as to what you mean about not installed properly. I note that you have your upgrade scheduled after InstallInitialize, and that means that you'll need to increment file versions to replace files and follow component rules if you're installing the same resources to the same locations. Maybe that's where the issue is.
I have a very simple WiX project (version 3.7) that installs somes files (a .NET program version 6.0.0.0). I'm ready to release a new version 6.0.1.0 using the MajorUpgrade functionality in WiX.
I'm keeping the UpgradeCode the same in the Product element and I change the Version from 6.0.0.0 to 6.0.1.0
<Product Id="*" Name="MyApp" Version="6.0.1.0" Manufacturer="Me"
UpgradeCode="$(var.TheUpgradeCodeGUID)">
On a machine with 6.0.0.0 installed, I run the new installer.
The removal of the old version 6.0.0.0 runs ok (all installed files are being removed), but when the installer continues to install the new version, 2 files are missing: a 3rd party DLL and a 3rd party EXE (that haven't been changed) are not being reinstalled.
<Component Id="AutomaticUpdaterWPF.dll" Guid="*">
<File Id="AutomaticUpdaterWPF.dll" Source="AutomaticUpdaterWPF.dll" KeyPath="yes" Checksum="yes" />
</Component>
<Component Id="wyUpdaterProgram" Guid="*">
<File Id="wyUpdaterProgram" Source="wyUpdate.exe" KeyPath="yes" Checksum="yes" />
</Component>
All other files in the < ComponentGroup > (some modified, some unmodified incl. other 3rd party DLLs) are being installed correctly during the major upgrade.
If I click on "repair" after the major upgrade, the 2 missing files re-appear.
Also, if I install version 6.0.1.0 for the first time (no upgrade, but first installation on a clean machine), then those 2 files are installed directly and normally.
(tested on several Windows machine (XP, 7 and 8)
Anybody any suggestion what is wrong and how to fix it?
The log file provided shows that newer versions of a few files already on the machine:
MSI (s) (0C:5C) [16:13:25:890]: Disallowing installation of component: {015A4DC1-56F4-562B-96B5-B3BE0D45FA5F} since the same component with higher versioned keyfile exists
MSI (s) (0C:5C) [16:13:25:890]: Disallowing installation of component: {4B6A1404-3892-5BEF-AB47-8FE3149211A4} since the same component with higher versioned keyfile exists
I've seen this problem with this updater in the past. Christopher is correct. The updater updated its files but didn't tell the MSI (it doesn't update the MSI which is not the correct thing to do). The new MSI thinks newer stuff is on the machine, chooses not to install its files, but during the upgrade the old package removes the files (it doesn't notice that the versions are newer). Since the new installer chose not to install the files you end up with nothing... until the repair.
To work around the problem, you need to move your RemoveExistingProducts action later. If you're using the MajorUpgrade element then Schedule='afterInstallExecute' or Schedule='afterInstallFinalize' should do the trick. You'll need to be more careful with the Component Rules.
Also, IMHO, the 3rd party vendor should not be updating files outside of the MSI. Their decision is forcing your product into a particular way of upgrading.
A log file would help. My guess is it's based on where you have scheduled RemoveExistingProducts. I've seen situations where Costing figures out a file being installed is the same as a file already installed and decides to not install the file. Then the major upgrade occurs and you end up not having the file. The repair works because the file isn't there and costing realizes that it needs to be installed.
I have had the same problem. The issue here is when doing major upgrade, msi at first checks which components to install (and all dlls with lower version than the ones already installed are marked as "do not install"), then it removes installed app and then installs new version but without those previously marked components.
Rescheduling of REP did not help since "disallowing installation (...)" was done in Costing phase and MajorUpgrade can only be scheduled in Install phase.
My solution was to set REINSTALLMODE property to "amus" in wxs file.
<Property Id="REINSTALLMODE" Value="amus" />
The "a" means all dlls will be reinstalled despite their versions.
I had another solution to this problem, but the previous reply certainly pointed me in the right direction. The DLLs in my .NET project were being assigned a lower version number than my previous installation. Going to the AssemblyInfo.cs files and incrementing the third octet from 0 to 1 solved it. Wix now recognized the DLLs as newer.
[assembly: AssemblyVersion("1.0.1.*")]
Error still exists on installer 5.0 and is still a problem.
Workaround to place RemoveExistingProduct after InstallFinalize is no solution for us. I forced the update by property setting on the single file.
This solution works for us now.
On older versions of Windows Installer the issue is documented here:
https://support.microsoft.com/en-us/kb/905238
The list of affected products inplies that it's fixed in MSI engine 4.0 and later. Using the 4.5 redistributable before doing installs should help, if applicable to the OS version.