I spent a few days on solving the problem with many versions of the boostrapper in Add/Remove Programs.
I have tried in many ways with different combinations of the DisableRemove, DisableModify, UpgradeCode, ParentName and Version for Bundle properties. I am tring attach to the event PlanRelatedBundle and DetectRelatedBundle but I am not able to set anything there.
Found this from 2012 but unfortunately there is no such definitive solution to this problem for bootstrapper. http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapper-Upgrade-Detection-td7580471i20.html
In logs I can see it find related bundle
First version 1.0.108.0:
[4364:38F8][2021-05-05T07:58:53]i370: Session begin, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{a0118d1b-5688-4e44-a1a9-61c7b7b4d9f0}, options: 0x7, disable resume: No
[4364:38F8][2021-05-05T07:58:54]i000: Caching bundle from: 'C:\Users\M4360~1\AppData\Local\Temp{82501D9E-759F-4960-9F6B-D34CB27DBC5B}.be\ETest.exe' to: 'C:\ProgramData\Package Cache{a0118d1b-5688-4e44-a1a9-61c7b7b4d9f0}\ETest.exe'
[4364:38F8][2021-05-05T07:58:54]i320: Registering bundle dependency provider: {a0118d1b-5688-4e44-a1a9-61c7b7b4d9f0}, version: 1.0.108.0
[4364:38F8][2021-05-05T07:58:54]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{a0118d1b-5688-4e44-a1a9-61c7b7b4d9f0}, resume: Active, restart initiated: No, disable resume: No
Second version 1.0.109.0:
[0FC0:2F94][2021-05-05T08:16:19]i000: *********** EVENT: PlanRelatedBundle, arg name: PlanRelatedBundleEventArgs - BundleId, value: {a0118d1b-5688-4e44-a1a9-61c7b7b4d9f0}. State, value: Absent. Result, value: None. , sender:: BootstrapperStartup
[0FC0:2F94][2021-05-05T08:16:19]i207: Planned related bundle: {a0118d1b-5688-4e44-a1a9-61c7b7b4d9f0}, type: Upgrade, default requested: Absent, ba requested: Absent, execute: Uninstall, rollback: Install, dependency: None
[2278:35D8][2021-05-05T08:16:22]i370: Session begin, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{e0e0d315-c8fc-4f19-acb0-01791a533e15}, options: 0x7, disable resume: No
[2278:35D8][2021-05-05T08:16:23]i000: Caching bundle from: 'C:\Users\M4360~1\AppData\Local\Temp{B525729B-76AE-4428-9F13-9DA529F2E455}.be\ETest.exe' to: 'C:\ProgramData\Package Cache{e0e0d315-c8fc-4f19-acb0-01791a533e15}\ETest.exe'
[2278:35D8][2021-05-05T08:16:23]i320: Registering bundle dependency provider: {e0e0d315-c8fc-4f19-acb0-01791a533e15}, version: 1.0.109.0
[2278:35D8][2021-05-05T08:16:23]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{e0e0d315-c8fc-4f19-acb0-01791a533e15}, resume: Active, restart initiated: No, disable resume: No
Third version 1.0.110.0:
[1C30:06C8][2021-05-05T08:26:14]i000: *********** EVENT: PlanRelatedBundle, arg name: PlanRelatedBundleEventArgs - BundleId, value: {a0118d1b-5688-4e44-a1a9-61c7b7b4d9f0}. State, value: Absent. Result, value: None. , sender:: BootstrapperStartup
[1C30:06C8][2021-05-05T08:26:14]i000: *********** EVENT: PlanRelatedBundle, arg name: PlanRelatedBundleEventArgs - BundleId, value: {e0e0d315-c8fc-4f19-acb0-01791a533e15}. State, value: Absent. Result, value: None. , sender:: BootstrapperStartup
[1C30:06C8][2021-05-05T08:26:14]i207: Planned related bundle: {a0118d1b-5688-4e44-a1a9-61c7b7b4d9f0}, type: Upgrade, default requested: Absent, ba requested: Absent, execute: Uninstall, rollback: Install, dependency: None
[1C30:06C8][2021-05-05T08:26:14]i207: Planned related bundle: {e0e0d315-c8fc-4f19-acb0-01791a533e15}, type: Upgrade, default requested: Absent, ba requested: Absent, execute: Uninstall, rollback: Install, dependency: None
GUID is correct, but I can't see anything in the logs more about previous versions and I can't see them being uninstalled.
I tried to add ParentName to the Bundle, but it causes no new version to show up in Add/Remove Programs and dont remove old.
Finally my installer installs 5 things, 4 of which are programs that need to be installed for my .msi and I don't know if these other versions are eventually uninstalled and only the registry remains? Why are they in Add / Remove Programs? Because when installing the next version of the boostrapper, it does not take up as much disk space as its entire size from 1.3gb takes about 200 / 300mb and my .msi has 170mb + logs.
Maybe deleting the registry in PlanRelatedBundle is enough?
Edit
I tried remove registery in event OnPlanRelatedBundle and I conclude that the bootstrapper does not have permission to delete registries during upgrade throws an error with RegistryKey key = key32.OpenSubKey (registryKey, true) ;. If I attache to the process when uninstall bootstrapper , the permissions are higher and successfully remove the registers of old versions of the boostrapper. But the installer increases the "Launched elevated engine process." Exe, running as administrator also does not make the old version uninstall.
I solved the problem by hooking to the OnPlanRelatedBundle event and removing the registries of older versions of the application.
However, this requires running the bootstrapper with administrative privileges.
private void OnPlanRelatedBundle(object sender, PlanRelatedBundleEventArgs e)
{
try
{
string registryKey = #"SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall";
RegistryKey key32 = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry32);
RegistryKey key = key32.OpenSubKey(registryKey, true);
if (key != null)
{
key.DeleteSubKeyTree(e.BundleId, false);
key.Close();
}
}
catch (Exception ex)
{
}
}
Related
I am using WiX bundle to apply multiple MSPs.
A MSP (hotfix.msp) is target to SP1 of product A. I created the hotfix.msp with "ProductValidateFlags" equal 0x00000922.
When I double click the MSP file directly, the hotfix.msp can be applied properly on product A with SP1 installed.
However, I created a WiX bundle package which include hotfix.msp, after the bundle is installed, the hotfix.msp isn't applied.
The log information:
[0118:02C4][2018-05-30T14:56:28]i106: Calculating patch applicability for target product code: {B8136533-98DA-40CD-BCB0-AC798AEB71B8}, context: Machine
[0118:02C4][2018-05-30T14:56:28]i101: Detected package: hotfix, state: Absent, cached: None
...
[0608:0904][2018-05-30T14:40:01]i200: Plan begin, 1 packages, action: Install
[0608:0904][2018-05-30T14:40:01]i201: Planned package: hotfix, state: Absent, default requested: Present, ba requested: Present, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0608:0904][2018-05-30T14:40:01]i000: Running plan complete BA function
Source code to include the MspPackage in WiX bundle:
<MspPackage Id="hotfix" DisplayName="Sample Hotfix" SourceFile="$(env.hotfix)" Permanent="no" Cache="yes" Vital="yes">
</MspPackage>
btw, the hotfix can be applied normally if I change the ProductValidateFlags to 0x902.
Thanks
Jeremy
I have a problem during the installation of SQL Server Data Tools for Visual Studio 2017
I get the following error (translated):
The requested meta file operation is not supported (0x800707D3)
Screenshot: See here
Log file available here:
https://www.dropbox.com/s/e34kry9ycj76j7n/SSDT-Setup-ENU_20171219090643.log?dl=0
Here's the relevant section from the linked log file:
[13C4:3020][2017-12-19T10:07:22]i000: MainViewModel.OnPackageActionProgress: Percent completed: 0, Overall progress: 27
[13C4:3020][2017-12-19T10:07:22]i000: MainViewModel.OnPackageActionProgress: Percent completed: 0, Overall progress: 27
[13C4:3020][2017-12-19T10:07:22]i000: MainViewModel.OnPackageActionProgress: Percent completed: 0, Overall progress: 27
[13C4:3020][2017-12-19T10:07:22]i000: MainViewModel.OnPackageActionProgress: Percent completed: 0, Overall progress: 27
[13C4:3020][2017-12-19T10:08:49]i000: MainViewModel.OnPackageActionProgress: Percent completed: 0, Overall progress: 27
[13C4:3020][2017-12-19T10:08:51]i000: MainViewModel.OnPackageActionProgress: Percent completed: 0, Overall progress: 27
[13C4:3020][2017-12-19T10:08:51]i000: MainViewModel.OnPackageActionProgress: Percent completed: 0, Overall progress: 27
[13C4:3020][2017-12-19T10:08:51]i000: MainViewModel.OnPackageAction: Install Completed for package SQL Server Integration Services 2012 (id: SSISOneDesigner2012)
[13C4:3020][2017-12-19T10:08:51]i319: Applied rollback package: SSISOneDesigner2012, result: 0x0, restart: None
[4214:2830][2017-12-19T10:08:51]i329: Removed package dependency provider: {DB97C76B-9116-42C5-8814-0041856EB9E6}, package: SSISOneDesigner2012
[4214:2830][2017-12-19T10:08:51]i329: Removed package dependency provider: Microsoft.DataTools.ReportingServices, package: Microsoft.DataTools.ReportingServices
[4214:2830][2017-12-19T10:08:51]i329: Removed package dependency provider: Microsoft.DataTools.AnalysisServices, package: Microsoft.DataTools.AnalysisServices
[13C4:3020][2017-12-19T10:08:51]i000: MainViewModel.OnPackageActionProgress: Percent completed: 100, Overall progress: 100
[4214:2830][2017-12-19T10:08:51]i372: Session end, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{058aacb1-dd61-42d2-951e-fc2d0b51c456}, resume: None, restart: None, disable resume: No
[4214:2830][2017-12-19T10:08:51]i330: Removed bundle dependency provider: {058aacb1-dd61-42d2-951e-fc2d0b51c456}
[4214:2830][2017-12-19T10:08:51]i352: Removing cached bundle: {058aacb1-dd61-42d2-951e-fc2d0b51c456}, from path: C:\ProgramData\Package Cache\{058aacb1-dd61-42d2-951e-fc2d0b51c456}\
[4214:2830][2017-12-19T10:08:51]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{058aacb1-dd61-42d2-951e-fc2d0b51c456}, resume: None, restart initiated: No, disable resume: No
[13C4:3020][2017-12-19T10:08:51]e000: MainViewModel.OnBundleAction: Bundle action failed: De aangevraagde metabestandsbewerking wordt niet ondersteund (0x800707D3)
[13C4:3020][2017-12-19T10:08:51]i399: Apply complete, result: 0x800707d3, restart: None, ba requested restart: No
[13C4:2DC4][2017-12-19T10:09:07]i000: MainViewModel.OpenUrl: Opening url: C:\Users\GEBRUI~1\AppData\Local\Temp\SsdtSetup\SSDT-Setup-ENU_20171219090643.log
[13C4:2DC4][2017-12-19T10:10:35]i000: MainViewModel.OpenUrl: Opening url:
C:\Users\GEBRUI~1\AppData\Local\Temp\SsdtSetup\SSDT-Setup-ENU_20171219090643.log
I have installed SQL Server Management Studio 17, and then SQL Server 2017 shortly before.
-
Can anyone help with this?
I got this attempting to install SSDT to Visual Studio 2019 (the only version of VS I have installed). Fixed by telling SSDT to install the standalone Visual Studio 2017 option, and installed the extension "SQL Server Integration Services Projects" in Visual Studio 2019.
I was getting the exact same error. I had to repair my instance of Visual Studio Professional 2017 as that is where I was installing the tools. After repairing that instance, had no problems with setting up SSDT. Luckily I had just installed Visual Studio so I didn't lose any configuration.
What worked for me, was to restart the computer and restart the installation of SSDT.
I installed Visual studio within the SSDT setup.
Download and install the following .vsix files from Microsoft(i got these link from log):
Microsoft.DataTools.IntegrationServices: https://go.microsoft.com/fwlink/?LinkId=871369
Microsoft.DataTools.AnalysisServices: https://go.microsoft.com/fwlink/?linkid=870525
Microsoft.DataTools.ReportingServices: https://go.microsoft.com/fwlink/?linkid=870526
I know this is an old question, but what worked for me was to right click on the SSDT installer (download it to your laptop/PC instead of running it from your browser) and run it as an administrator. I was lucky enough to get it to work without any other steps.
In my case SSISOneDesigner2014.msi was giving me an error to download in the log, and the only workaround was executing the offline SSDT install since I've already had a Visual Studio 2017 instance, executing
SSDT-Setup-ENU.exe /layout c:\<filepath>
(Where filepath is any location you want to download installer files.)
Then, manually download SSISOneDesigner2014.msi and copy in c:\<filepath>\payload
After that execute the following:
SSDT-Setup-ENU.exe /install
This correctly installed the rest of the components.
I have an burn standard bootstrapper which chains one particular msi as follows
<Chain>
...
<MsiPackage Id="activex32" Cache="yes" SourceFile="$(var.MyPath)\activex32.msi" />
...
</Chain>
This msi follows the MajorUpgrade strategy: each build changes PackageCode and ProductCode, but keeps the UpgradeCode constant through builds.
The problem is, some people actually install this msi as a standalone package. And some of these people also want to install my bootstrapper, which was compiled with an older version of activex32.msi (lower build number). When this happens, the bootstrapper downgrades the activex32.msi.
I would like to know how to prevent this downgrading. Yes, I can update my bootstrapper with the latest activex32.msi, but that does not prevent the problem from happening again in the future.
Update:
The log doesn't say much, in my opinion
[120C:14C8][2017-10-20T16:49:05]i103: Detected related package: {1CFD803C-D610-4414-B308-28FDD8326542}, scope: PerMachine, version: 8.11.0.19409, language: 0 operation: MajorUpgrade
[120C:14C8][2017-10-20T16:49:05]i101: Detected package: activex32, state: Absent, cached: None
[120C:14C8][2017-10-20T16:49:07]i201: Planned package: activex32, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[0CD8:0C04][2017-10-20T16:49:10]i305: Verified acquired payload: activex32 at path: C:\ProgramData\Package Cache.unverified\activex32, moving to: C:\ProgramData\Package Cache{21C87035-C870-4C06-8978-290D4FD71D33}v8.11.0.18409\activex32.msi.
[0CD8:0C04][2017-10-20T16:49:10]i305: Verified acquired payload: activex32 at path: C:\ProgramData\Package Cache.unverified\activex32, moving to: C:\ProgramData\Package Cache{21C87035-C870-4C06-8978-290D4FD71D33}v8.11.0.18409\activex32.msi.
[0CD8:12F8][2017-10-20T16:49:41]i323: Registering package dependency provider: {21C87035-C870-4C06-8978-290D4FD71D33}, version: 8.11.0.18409, package: activex32
[0CD8:12F8][2017-10-20T16:49:41]i301: Applying execute package: activex32, action: Install, path: C:\ProgramData\Package Cache{21C87035-C870-4C06-8978-290D4FD71D33}v8.11.0.18409\activex32.msi, arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7"'
[120C:14C8][2017-10-20T16:49:43]i319: Applied execute package: activex32, result: 0x0, restart: None
[0CD8:12F8][2017-10-20T16:49:43]i325: Registering dependency: {eb25107d-62c4-49d9-a7c8-0957943ccbdb} on package provider: {21C87035-C870-4C06-8978-290D4FD71D33}, package: activex32
I did some more investigation and concluded that burn does not do much, if anything at all (?), to allow or disallow downgrades. It seems to leave that decision to the msi package itself.
In my case, the activex32.msi allows downgrading. When I changed it with Orca, modifying the Upgrade table to disallow downgrades, and compiled a new bootstrapper using this modified package, then everything worked and burn didn't downgrade the existing activex32.msi.
Kind of disappointing, since I don't control how the 3rd-party package is built.
Before I started creating my own custom Managed Bootstrapper Application, I was using the existing Fragment below with no issues, i.e. it would download the .msi from the internet if the local file was not found. Now when I try to execute the MBA I get the error below in the log file.
[Environment]
WiX 3.7, Visual Studio 2012, x64
[Bundle.wxs]
<PackageGroupRef Id="ReportViewer"/>
[Fragment.wxs]
<PackageGroup Id="ReportViewer">
<MsiPackage DisplayName="Microsoft Report Viewer 2012 Runtime"
Cache="no" Compressed="no" ForcePerMachine="yes" Permanent="yes" Vital="yes"
SourceFile="C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Packages\ReportViewer\ReportViewer.msi"
DownloadUrl="http://go.microsoft.com/fwlink/?LinkID=217022"
InstallCondition="(VersionNT >= v6.0 OR VersionNT64 >= v6.0)"/>
</PackageGroup>
[Log]
[14:42]i101: Detected package: ReportViewer.msi, state: Absent, cached: None
[14:54]i201: Planned package: ReportViewer.msi, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: None, cache: Yes, uncache: Yes, dependency: Register
[15:00]w343: Prompt for source of package: ReportViewer.msi, payload: ReportViewer.msi, path: E:\ReportViewer.msi
[15:00]e054: Failed to resolve source for file: E:\ReportViewer.msi, error: 0x80070002.
[15:00]e000: Error 0x80070002: Failed while prompting for source (original path 'E:\ReportViewer.msi').
[15:00]e313: Failed to acquire payload: ReportViewer.msi to working path: C:\Users\POS1User\AppData\Local\Temp{416b9117-e1b4-4518-b13d-eb5416da8794}\ReportViewer.msi, error: 0x80070002.
When a package is not present locally, the Burn engine asks your bootstrapper application to deal with the ResolveSource call. As explained in this other Stack Overflow answer, you should add your own event handler for the ResolveSource event. You can simply instruct Burn to download the package for you:
this.Bootstrapper.ResolveSource += OnResolveSource;
...
private void OnResolveSource(object sender, ResolveSourceEventArgs e)
if (!File.Exists(e.LocalSource) && !string.IsNullOrEmpty(e.DownloadSource))
e.Result = Result.Download;
}
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.
Why do previous versions show up on completion?
Is it because they are cached?
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
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