WiX installer fails to uninstall MSI package Error 0x80070643 - wix

I have used the WiX toolkit to create an installer. The installer bundle.wxs file has 4 msi packages that I am installing sequentially. Here's the code for the bundle.wxs :
<chain>
<MsiPackage Id="MSOLEDBSQLDriver"
SourceFile="..\..\..\..\..\..\third-party\MSOLEDBSQL\msoledbsql.msi"
DisplayInternalUI="no"
Compressed="yes"
Vital="yes"
ForcePerMachine="yes">
<MsiProperty Name="IACCEPTMSOLEDBSQLLICENSETERMS" Value="YES" />
<MsiProperty Name="ACCEPTEULA" Value="1" />
</MsiPackage>
<MsiPackage Id="MSODBCSQL"
SourceFile="..\..\..\..\..\..\third-party\SQL Server Express\msodbcsql.msi"
DisplayInternalUI="no"
Compressed="yes"
Vital="yes"
ForcePerMachine="yes">
<MsiProperty Name="IACCEPTMSODBCSQLLICENSETERMS" Value="YES" />
<MsiProperty Name="ACCEPTEULA" Value="1" />
</MsiPackage>
<MsiPackage Id="MSSQLCMDLNUTILS"
SourceFile="..\..\..\..\..\..\third-party\SQL Server Express\MsSqlCmdLnUtils.msi"
DisplayInternalUI="no"
Compressed="yes"
Vital="yes"
ForcePerMachine="yes">
<MsiProperty Name="IACCEPTMSSQLCMDLNUTILSLICENSETERMS" Value="YES" />
<MsiProperty Name="ACCEPTEULA" Value="1" />
</MsiPackage>
<RollbackBoundary />
<MsiPackage Id="MainPackage"
SourceFile="..\Application\bin\Release\ApplicationInstaller.msi"
DisplayInternalUI="yes"
Compressed="yes"
Vital="yes">
<MsiProperty Name="INSTALLDIR" Value="CSNode" />
<MsiProperty Name="CONFIGFILE" Value="[CONFIGFILE]"/>
<MsiProperty Name="AddDesktopShortcut" Value="[AddDesktopShortcutMsiVariable]" />
</MsiPackage>
</Chain>
The installation goes well without any issues, however when I try to uninstall the application from program and features, I get a setup failed message with the following log in my Temp folder :
[1C78:092C][2022-03-16T13:38:45]i326: Removed dependency: {7dd16205-28b8-46f2-bc9f-b85e6a7b0525} on package provider: {EDA3FABE-E481-4E69-A7B0-E845DF0FEC22}, package MSSQLCMDLNUTILS
[1C78:092C][2022-03-16T13:38:45]i329: Removed package dependency provider: {EDA3FABE-E481-4E69-A7B0-E845DF0FEC22}, package: MSSQLCMDLNUTILS
[1C78:092C][2022-03-16T13:38:45]i301: Applying execute package: MSSQLCMDLNUTILS, action: Uninstall, path: (null), arguments: ' ALLUSERS="1" ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" IACCEPTMSSQLCMDLNUTILSLICENSETERMS="YES" ACCEPTEULA="1"'
[1C78:092C][2022-03-16T13:38:45]e000: Error 0x80070643: Failed to uninstall MSI package.
[1C78:092C][2022-03-16T13:38:45]e000: Error 0x80070643: Failed to execute MSI package.
[139C:1398][2022-03-16T13:38:45]e000: Error 0x80070643: Failed to configure per-machine MSI package.
[139C:1398][2022-03-16T13:38:45]i319: Applied execute package: MSSQLCMDLNUTILS, result: 0x80070643, restart: None
[139C:1398][2022-03-16T13:38:45]e000: Error 0x80070643: Failed to execute MSI package.
[1C78:092C][2022-03-16T13:38:45]i318: Skipped rollback of package: MSSQLCMDLNUTILS, action: Install, already: Present
[139C:1398][2022-03-16T13:38:45]i319: Applied rollback package: MSSQLCMDLNUTILS, result: 0x0, restart: None
[1C78:092C][2022-03-16T13:38:45]i323: Registering package dependency provider: {EDA3FABE-E481-4E69-A7B0-E845DF0FEC22}, version: 15.0.2000.5, package: MSSQLCMDLNUTILS
[1C78:092C][2022-03-16T13:38:45]i325: Registering dependency: {7dd16205-28b8-46f2-bc9f-b85e6a7b0525} on package provider: {EDA3FABE-E481-4E69-A7B0-E845DF0FEC22}, package: MSSQLCMDLNUTILS
There are some other questions related to this issue and based on that I added the ForcePerMachine="yes" parameter but that doesn't work either. I have been trying to figure out how to fix that but haven't found a solution which works for me.
Can someone please help me?

Related

Permissions problem with Wix Custom Action and Burn bootstrapper

I have a package that needs to be installed with elevated administrator privileges. However, this installer includes an uninstall custom action to run a clean-up executable, which must be run as the local user.
This all works fine for the generated MSI (install and uninstall), but when I wrap the MSI up in a Burn bootstrapper, the uninstall custom action is instead run as the administrator - and hence fails...
My application must be installed “perMachine”, and so in my Product.wxs I have my package setup with
InstallPrivileges="elevated"
InstallScope="perMachine"
However, this application's uninstaller includes an uninstall custom action to run a clean-up executable, which must be run as the local user (since it looks for a file in the user’s App-Data). So I’ve set the CustomAction to
Impersonate="yes" Execute="immediate"
And have:
<InstallExecuteSequence>
<Custom Action="UninstallCleanup" Before="RemoveFiles">
(NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")
</Custom>
</InstallExecuteSequence>
This builds my MSI file, which I can then install on my machine. When I then run the uninstall, either via the Control Panel or manually (msiexec /x MyInstaller.msi /l* Testing.log), I am prompted for an admin password, the application is uninstalled, and the custom action is run as the local user. Everything perfect.
BUT I need to wrap this MSI up in a WiX Burn bootstrapper EXE that also installs pre-requisites (the VC runtime) before running my MSI package. Now when this Package Bundle is installed, and then uninstalled via the control panel, my MSI uninstall custom action is run as the administrator rather than the local user - and so fails.
In my Bundle.wxs file I have:
<PackageGroup Id="PP_Package">
<MsiPackage
Compressed="yes"
EnableFeatureSelection="no"
SourceFile="$(var.PP_MSI_PATH)"
Permanent="no"
DisplayInternalUI="no"
Visible="no"
Vital="yes">
<MsiProperty Name="INSTALLFOLDER" Value="[InstallFolder]" />
</MsiPackage>
</PackageGroup>
And
<PackageGroup Id="VCRedist">
<ExePackage Id="vcRedist_x86"
Cache="yes"
Compressed="yes"
PerMachine="yes"
Permanent="yes"
Vital="yes"
SourceFile="$(var.VCREDIST_X86_LOC)\$(var.VCREDIST_X86_FILE)"
Name="Redist\$(var.VCREDIST_X86_FILE)"
InstallCommand="/install /quiet /norestart"
Protocol="burn">
<ExitCode Value="1638" Behavior="success" />
<ExitCode Value ="3010" Behavior="forceReboot" />
</ExePackage>
</PackageGroup>
And then:
<Chain>
<PackageGroupRef Id="VCRedist" />
<RollbackBoundary Vital="yes" />
<PackageGroupRef Id="PP_Package" />
</Chain>
What have I got wrong? Is the issue something like: WiX Burn detects that the MSI is perMachine and so starts it using elevated admin, so that the custom action interprets Impersonate="yes" as meaning the administrator rather than the local user?
Any help, explanations and solutions would be most welcome.

Wix bootstrapper webinstaller does not download msi-file

In my bootstrapper I want to install one package as a webinstallation. Therefore I added the following MsiPackage to the Bundle´s Chain
<MsiPackage DisplayInternalUI="yes" Visible="yes" Id="NodeJs"
Compressed="no"
ForcePerMachine="yes"
SourceFile="node-v0.10.32-x86.msi"
DownloadUrl="https://nodejs.org/dist/v0.10.32/node-v0.10.32-x86.msi">
<MsiProperty Name="INSTALLFOLDER" Value="[Global_InstallFolder]\NodeJs" />
However, the installation only works as expected when the to-download-msi-file is in the same directory as the bootstrapper-exe.
In other words, it does not download the msi-file.
What am I doing wrong?

Wix - Burn tool - How to notify error or failure due to non-vital package in the chain

In my wix bundle I have chain of multiple Packages (see below), out of those if my App2 fails to install still I need to continue with the rest of the installation but at the end would like to show failure message reported by App2 package. Any suggestion on how to implement this?
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<!-- TODO: Define the list of chained packages. -->
<!-- <MsiPackage SourceFile="path\to\your.msi" /> -->
<PackageGroupRef Id="NetFx462Web"/>
<MsiPackage Id="App1" SourceFile="App1.msi" DisplayInternalUI='yes' Compressed ="yes" />
<RollbackBoundary />
**<MsiPackage Id="App2" SourceFile="App2.msi" Permanent="yes" Visible="yes" DisplayInternalUI='no' Vital='no' Compressed ="yes" />**
<PackageGroupRef Id="App3"/>
<PackageGroupRef Id="App4" />
</Chain>

Chain dependant msi packages with burn

I have been struggling now for a few hours getting this working without any real success. I am trying to install ReportViewer 2012 (v11) including SQLSysClrTypes.msi with my installer.
My registry checks are as follow and seems to work:
<util:RegistrySearch Root="HKLM"
Key="SOFTWARE\Microsoft\Microsoft SQL Server 2012 Redist\SQL Server System CLR Types\CurrentVersion"
Value="Version"
Variable="SQLSysClrTypesVerion" />
<util:RegistrySearch Root="HKLM"
Key="Software\Microsoft\Microsoft SQL Server 2012 Redist\Microsoft Report Viewer 2012 Runtime"
Value="Version"
Variable="ReportViewer11Verion" />
The package ref is as follow:
<PackageGroup Id="ReportViewer11">
<ExePackage Id="SQLSysClrTypes" Cache="no" Compressed="yes" PerMachine="yes" Permanent="yes" Vital="yes"
SourceFile="reportviewer/SQLSysClrTypes.msi"
DownloadUrl="http://go.microsoft.com/fwlink/?LinkID=239643&quote;clcid=0x409"
DetectCondition="SQLSysClrTypesVerion" />
<ExePackage Id="ReportViewer11" Cache="no" Compressed="yes" PerMachine="yes" Permanent="yes" Vital="yes"
InstallCommand="/q"
SourceFile="reportviewer/ReportViewer.msi"
DownloadUrl="http://www.microsoft.com/en-us/download/details.aspx?id=35747"
DetectCondition="ReportViewer11Verion" />
</PackageGroup>
The log file for the installer states the following (not really helpful):
[0F08:10E0][2015-04-20T16:47:00]i304: Verified existing payload: ReportViewer11 at path: C:\ProgramData\Package Cache\54004C9B82D761A9AEB4EB73B85F5475D3771BAE\ReportViewer.msi.
[0F08:10E0][2015-04-20T16:47:00]i304: Verified existing payload: InstallationPackageId at path: C:\ProgramData\Package Cache{A327D350-C9A6-4AA5-AA86-92E3B6653E77}v1.0.0.0\Avis.RAC.DARA.msi.
[0F08:04A4][2015-04-20T16:47:00]i301: Applying execute package: ReportViewer11, action: Install, path: C:\ProgramData\Package Cache\54004C9B82D761A9AEB4EB73B85F5475D3771BAE\ReportViewer.msi, arguments: '"C:\ProgramData\Package Cache\54004C9B82D761A9AEB4EB73B85F5475D3771BAE\ReportViewer.msi" /q'
[0F08:04A4][2015-04-20T16:47:00]e000: Error 0x800700c1: Failed to CreateProcess on path: C:\ProgramData\Package Cache\54004C9B82D761A9AEB4EB73B85F5475D3771BAE\ReportViewer.msi
[0F08:04A4][2015-04-20T16:47:00]e000: Error 0x800700c1: Failed to execute EXE package.
[0E24:1164][2015-04-20T16:47:00]e000: Error 0x800700c1: Failed to configure per-machine EXE package.
[0E24:1164][2015-04-20T16:47:00]i319: Applied execute package: ReportViewer11, result: 0x800700c1, restart: None
[0E24:1164][2015-04-20T16:47:00]e000: Error 0x800700c1: Failed to execute EXE package.
You are using ExePackage for your msi files, use MsiPackage instead.

WiX - Does Burn support dual-purpose msi packages?

Does Burn support dual-purpose (per-user or per-machine) MSI packages which were prepared according to these Microsoft guidelines?
I tried to prepare such a package, but it looks like bootstrapper created with Burn doesn't uninstall MSI package, which was installed per-machine after raising UAC privileges by End-User.
The source code for Burn is:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Version="1.0"
Name="AppNameHere"
UpgradeCode="GuidHere">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.HyperlinkLicense" >
<bal:WixStandardBootstrapperApplication LicenseUrl=""
SuppressOptionsUI="yes"
ThemeFile="Customization\Theme.xml"
LocalizationFile="Customization\LangHere.wxl"/>
</BootstrapperApplicationRef>
<Chain>
<PackageGroupRef Id="WindowsInstaller45"/>
<PackageGroupRef Id="NetFx40ClientRedist"/> <!-- Uzywa rozszerzenia WixNetfxExtension do zainstalowania .net -->
<PackageGroupRef Id="vcredist"/>
<MsiPackage Compressed="yes"
SourceFile="MsiFileNameHere"
DisplayInternalUI="yes">
<MsiProperty Name="UPDATEDIR" Value="[UninstallPath]"/>
<MsiProperty Name="WIXBUNDLEKEY" Value="[WixBundleProviderKey]"/>
</MsiPackage>
</Chain>
</Bundle>
<Fragment>
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\Microsoft\VisualStudio\10.0\VC\VCRedist\x86" Value="Installed" Variable="vcredistkeyx86" />
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\VC\VCRedist\x86" Value="Installed" Variable="vcredistkeyx64" />
<PackageGroup Id="vcredist">
<ExePackage Id="vcredist_x86"
Cache="no"
Compressed="yes"
PerMachine="yes"
Permanent="yes"
Vital="yes"
SourceFile="Components\vcredist_x86.exe"
DetectCondition="(vcredistkeyx86 AND (vcredistkeyx86 >= 1)) OR (vcredistkeyx64 AND (vcredistkeyx64 >= 1))" />
</PackageGroup>
<PackageGroup Id="WindowsInstaller45">
<ExePackage Cache="no"
Compressed="yes"
PerMachine="yes"
Permanent="yes"
Vital="yes"
SourceFile="Components\WindowsXP-KB942288-v3-x86.exe"
InstallCondition="VersionNT=v5.1 AND NOT VersionNT64 AND VersionMsi < v4.5"
InstallCommand="/quiet /norestart">
<ExitCode Behavior="forceReboot"/>
</ExePackage>
</PackageGroup>
</Fragment>
</Wix>
As of WIX V3.9 the answer is a qualified "No" - Burn doesn't currently support dual-purpose per-user or per-machine MSI package.
A dual-purpose MSI package has the ALLUSERS property set to "2". When you build a WIX bootstrapper project referencing this type of MSI package you should see this type of warning:
2>D:\Robert\Documents\Visual Studio 2013\Projects\BurnTest\Bootstrapper\Bundle.wxs(18,0): warning LGHT1133: Bundles require a package to be either per-machine or per-user. The MSI 'D:\Robert\Documents\Visual Studio 2013\Projects\BurnTest\SetupProject\bin\Release\SetupProject.msi' ALLUSERS Property is set to '2' which may change from per-user to per-machine at install time. The Bundle will assume the package is per-machine and will not work correctly if that changes. If possible, remove the Property with Id='ALLUSERS' and use Package/#InstallScope attribute instead.
The build process for a WIX bootstrapper project will try and work out from the chained packages what type of burn installation to create (per-user or per-machine). The logic is convoluted because of the different places you can declare a preference for per-user or per-machine, and the potential conflicts between chained packages. But the general idea is the burn compiler will generate a per-machine installation, unless one of the chained packages is per-user, which will flip the burn installation into per-user mode. The key point is the decision to create a per-user or per-machine package is made at build time. To properly support dual-purpose MSI packages that decision would need to be moved to install time.