2

I was developing my Bootstrapper project (with customBA) with version 3.28 for a while.

Before delivering I changed it to 3.29 and tested it.

When 3.29 completes it calls the previous versions that were installed in the machine.

I clicked on Cancel on the previous version screens to close them.

  1. Why do previous versions show up on completion?
  2. Is it because they are cached?
  3. How can one avoid this from happening?

UPDATE
Is it because of the UpgradeCode being similar that it searches for related bundles?
If yes should I disable caching or define upgrade behavior?

The following log file run by the old bootstrapper says that "This bundle is being run by a related bundle as type 'Upgrade'. How do I stop this action?

[0B0C:2F34][2013-08-13T09:40:09]i001: Burn v3.7.1224.0, Windows v6.1 (Build 7601: Service Pack 1), path: C:\ProgramData\Package Cache\{b9f02a31-dacf-4347-b0d9-523d558be9af}\App1.Bootstrapper.exe, cmdline: '-uninstall -quiet -burn.related.upgrade -burn.embedded BurnPipe.{816C6916-20FF-4170-B29B-840713FCD78D} {84E89FE4-BE80-4A73-A176-FAF22D4C459F} 12176 -burn.unelevated BurnPipe.{55C769EC-EB8D-4196-BFA4-A4D4DB3390DB} {953972A4-1945-4ABB-AA00-3A323155D1D0} 9756'
[0B0C:2F34][2013-08-13T09:40:09]i003: This bundle is being run by a related bundle as type 'Upgrade'.
[0B0C:2F34][2013-08-13T09:40:09]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\Ranjith\AppData\Local\Temp\App1.Bootstrapper_20130813094009.log'
[0B0C:2F34][2013-08-13T09:40:09]i000: Loading managed bootstrapper application.
[0B0C:2F34][2013-08-13T09:40:09]i000: Creating BA thread to run asynchronously.
[0B0C:1214][2013-08-13T09:40:09]i000: Setting string variable 'INSTALLER_LANGUAGE' to value 'en-US'
[0B0C:1214][2013-08-13T09:40:09]i000: Setting default INSTALLER_LANGUAGE as en-US
[0B0C:2F34][2013-08-13T09:40:10]i100: Detect begin, 4 packages
[0B0C:2F34][2013-08-13T09:40:10]i102: Detected related bundle: {17819140-8d62-4611-8636-2e672025ec96}, type: Upgrade, scope: PerMachine, version: 3.29.0.0, operation: None
[0B0C:2F34][2013-08-13T09:40:10]i102: Detected related bundle: {f5896a5a-1734-45ff-a55b-d9801f87bed3}, type: Upgrade, scope: PerMachine, version: 3.29.0.0, operation: None
[0B0C:2F34][2013-08-13T09:40:10]i103: Detected related package: {49CEDE58-FA13-49C9-8900-B9B71BADAC90}, scope: PerMachine, version: 3.29.0.0, language: 0 operation: Downgrade
[0B0C:2F34][2013-08-13T09:40:10]i103: Detected related package: {49CEDE58-FA13-49C9-8900-B9B71BADAC90}, scope: PerMachine, version: 3.29.0.0, language: 0 operation: Downgrade
[0B0C:2F34][2013-08-13T09:40:10]i101: Detected package: App1.Prerequisites.SQLServer_setup.exe, state: Absent, cached: Complete
[0B0C:2F34][2013-08-13T09:40:10]i101: Detected package: App1.Prerequisites_setup.exe, state: Absent, cached: Complete
[0B0C:2F34][2013-08-13T09:40:10]i101: Detected package: App1.Setup.en, state: Obsolete, cached: Complete
[0B0C:2F34][2013-08-13T09:40:10]i101: Detected package: App1.Setup.de, state: Obsolete, cached: None
[0B0C:2F34][2013-08-13T09:40:10]i199: Detect complete, result: 0x0
[0B0C:1214][2013-08-13T09:40:12]i000: Cancelling...
[0B0C:2F34][2013-08-13T09:40:12]i500: Shutting down, exit code: 0x0
[0B0C:2F34][2013-08-13T09:40:12]i410: Variable: INSTALLER_LANGUAGE = en-US
[0B0C:2F34][2013-08-13T09:40:12]i410: Variable: WixBundleAction = 3
[0B0C:2F34][2013-08-13T09:40:12]i410: Variable: WixBundleElevated = 1
[0B0C:2F34][2013-08-13T09:40:12]i410: Variable: WixBundleInstalled = 1
[0B0C:2F34][2013-08-13T09:40:12]i410: Variable: WixBundleLastUsedSource = D:\Projects\Client\App1\Development\trunk\src\App1_Installers\App1.Bootstrapper\bin\Release\
[0B0C:2F34][2013-08-13T09:40:12]i410: Variable: WixBundleLog = C:\Users\Ranjith\AppData\Local\Temp\App1.Bootstrapper_20130813094009.log
[0B0C:2F34][2013-08-13T09:40:12]i410: Variable: WixBundleManufacturer = Client GmbH
[0B0C:2F34][2013-08-13T09:40:12]i410: Variable: WixBundleName = 
[0B0C:2F34][2013-08-13T09:40:12]i410: Variable: WixBundleOriginalSource = D:\Projects\Client\App1\Development\trunk\src\App1_Installers\App1.Bootstrapper\bin\Release\App1.Bootstrapper.exe
[0B0C:2F34][2013-08-13T09:40:12]i410: Variable: WixBundleProviderKey = {b9f02a31-dacf-4347-b0d9-523d558be9af}
[0B0C:2F34][2013-08-13T09:40:12]i410: Variable: WixBundleTag = 
[0B0C:2F34][2013-08-13T09:40:12]i410: Variable: WixBundleVersion = 3.28.0.0
[0B0C:2F34][2013-08-13T09:40:12]i007: Exit code: 0x0, restarting: No
Ranjith Venkatesh
  • 1,322
  • 3
  • 20
  • 57

1 Answers1

2

Yes that's the normal behavior, it is because of the same upgrade code. When it see's a similar upgrade code, it knows that these are related packages and then installs newer one and uninstalls the previous one.

You can get by this by changing the productcode and upgradecode for the second version and these would be 2 independent products, change it both at bundle and MSI level That would be the easiest solution.

If you take out the upgrade code, then the bundles would be completely independent and wont know that they are related, so they will be getting installed as a completely new package. Or you can set the RELATEDBUNDLE Element element to just "DETECT".

I have tried this on regular MSI's and for regular MSI's we use the:

OnlyDetect YesNoType Set to "yes" to detect products and applications but do not uninstall.

in the UPGRADEVERSION Element.

If you are planning to use the same upgrade code, then make sure that the Customaction FINDRELATEDPRODUCT and REMOVEEXISTINGPRODUCTS are suppressed.

You will need to update both RelatedBundle and the UpgradeVersion within the MSI too as burn handles the upgrades both at the bundle and also at the MSI level. See this question: stackoverflow.com/questions/13052950/wix-burn-uninstallation I had the similar question sometime back and had some email communication with Rob Mensching, he mentioned that the upgrades are handled both at bundle level and also the package level.

Why do you not want the previous version to be installed? Usually the best practice is to upgrade, why are you moving away from it?

Make sure that the packaged MSI's which you are installing are capable of co-existing. Usually it means trouble, since it will be installing the files to the common location and you dont know which version is existing where.

Read this article about Component Rules. Also if you are going this route you can make use of the WixPath attribute in your MSI. WIXPATH

Community
  • 1
  • 1
Isaiah4110
  • 9,855
  • 1
  • 40
  • 56
  • Does the usage of RelatedBundle in the Bootstrapper mean that the Upgrade element may be skipped in the MsiPackage? – Ranjith Venkatesh Aug 15 '13 at 08:46
  • You will need to update both RelatedBundle and the UpgradeVersion within the MSI too as burn handles the upgrades both at the bundle and also at the MSI level. See this question: http://stackoverflow.com/questions/13052950/wix-burn-uninstallation I had the similar question sometime back and had some email communication with Rob Mensching, he mentioned that the upgrades are handled both at bundle level and also the package level. – Isaiah4110 Aug 15 '13 at 13:18
  • I had only changed RelatedBundle in the Bootstrapper and the uninstall was still called. I need to test the changes in Exe and Msi Packages and then mark the answer. Thanks Isaiah42110 for your input – Ranjith Venkatesh Aug 16 '13 at 11:09
  • When I add related bundle with detect and upgrade version with detect, the new Msi does not get installed! – Ranjith Venkatesh Aug 19 '13 at 07:02
  • Change the top-level productcode and UpgradeCode GUIDs for the second version and they will become completely independent of each other. – Isaiah4110 Aug 19 '13 at 13:23
  • Also you might want to look at the Keypath attribute and the other link I have updated in the answer above. – Isaiah4110 Aug 19 '13 at 13:23
  • If you are planning to use the same upgrade code, then make sure that the Customaction [FINDRELATEDPRODUCT] and [REMOVEEXISTINGPRODUCTS] are suppressed. – Isaiah4110 Aug 19 '13 at 13:32