WIX bootstrapper fails on MSI package with 'optional' CAB files - wix

Using WIX 3.10:
I authored a MSI package using a few external CAB files.
Sometimes we deploy over network and we omit one or more CAB files (which contain files not needed for program execution). On installation we deselect corresponding features. There is no problem with missing CABs in that case.
Now I authored a bootstrapper with managed BA.
In chain of packages I set 'Cache=no':
<MsiPackage Id="MyInstaller"
Compressed="no" Visible="no" ForcePerMachine="yes"
EnableFeatureSelection="yes"
Cache="no"
SourceFile="$(var.MyPackageFileName)">
The problem is: on runtime the bootstrapper verifies presence of all packages and theirs CAB files (if any). It does so before the execution of all packages in the chain.
From log (shortened):
Acquiring package: MyInstaller, payload: MyInstaller, copy from: D:\X\MX-8-2-0-77-x86-Release.msi
Setting string variable 'WixBundleLastUsedSource' to value 'D:\X\'
Verified acquired payload: MyInstaller at path: C:\ProgramData\Package Cache\.unverified\MyInstaller, moving to: C:\ProgramData\Package Cache\{970B002C-448C-46E8-856C-5F9C5B234AB4}v8.2.0.77\MX-8-2-0-77-x86-Release.msi.
Acquiring package: MyInstaller, payload: cab502ABC9C22436673DD367A3B0E989121, copy from: D:\X\MX-8-2-0-77-x86-Release-Data.CAB
Verified acquired payload: cab502ABC9C22436673DD367A3B0E989121 at path: C:\ProgramData\Package Cache\.unverified\cab502ABC9C22436673DD367A3B0E989121, moving to: C:\ProgramData\Package Cache\{970B002C-448C-46E8-856C-5F9C5B234AB4}v8.2.0.77\MX-8-2-0-77-x86-Release-Data.CAB.
Prompt for source of package: MyInstaller, payload: cabBC894B366CE86BC776B6C0F16A45AEC9, path: D:\X\MX-8-2-0-77-x86-Release-HelpAndDoc.CAB
Failed to resolve source for file: D:\X\MX-8-2-0-77-x86-Release-HelpAndDoc.CAB, error: 0x80070002.
Error 0x80070002: Failed while prompting for source (original path 'D:\X\MX-8-2-0-77-x86-Release-HelpAndDoc.CAB').
Failed to acquire payload: cabBC894B366CE86BC776B6C0F16A45AEC9 to working path: C:\Users\CHRIST~1.THI\AppData\Local\Temp\{3CF902F0-06EB-46E8-BECF-900FA010D2EC}\cabBC894B366CE86BC776B6C0F16A45AEC9, error: 0x80070002.
Error 0x80070002: Failed while caching, aborting execution.
I don't want a prompt for missing files. I don't want to download missing files. And I don't want verification of CABs. Hence I disabled package caching. But WIX boostrapper host seems to ignore that.
All CAB files are also present in 'BootstrapperApplicationData.xml' which is created at compile time. But I did not mention them in bootstrapper sources. WIX burn obviously analyzes the packages.
How to make the bootstrapper host ignore missing CAB files for one MSI package?

Burn doesn't support that scenario. It assumes the .cabs in your package are needed and always verifies all packages and payloads.

Related

Unable to uninstall software installed using Wix MSI installer

I used the Wix tool in Visual Studio 2015 to generate an msi in a custom directory - not in Program Files. The software got installed alright (only for current user) but I am unable to uninstall it.
The error shown is: The specified path 'H:\Config.Msi\' is unavailable.
However, a folder with name exists at the specified path. Also, the uninstallation succeeds when I delete the contents of the folder created by the installer.
Any ideas on how I can get the software to uninstall cleanly?
The problem was that the referenced path H: was a virtual drive that caused the error. Mapping TARGETDIR to reference the correct path was a work-around. For my use case, this was sufficient.

MSI build through octopus

I have generated an MSI using Wix for the deployment we used octopus. While running the msi build through octopus some files like dlls, .. are not getting updated in the respective path for the first time of deployment. If we install the same for second time then works fine all the files placed in the folder.
These are the steps I have followed:
I have created a Wix project and generated a msi build through that. Then through the octopus using .xml file I have deployed the content in the specified folder. And deployment was not successful through octopus.
You really haven't given any information to troubleshoot. Are you using major upgrades or minor upgrades? What's your command line? Have you logged the installers and read through the logs? What do they tell you?
msiexec /i example.msi /qn /l*v install.log
/qn = silent /l*v = verbose logging
My first suspect is that you aren't versioning your DLL's correctly and that Windows Installer is skipping over them. Please see:
File Versioning Rules
Default File Versioning
Replacing Existing Files

How do you stop WiX from passing ARPSYSTEMCOMPONENT="1" when executing MSI files in a chain?

In "Bundle.wxs" I have a "chain" with "MsiPackage"s that are applied in sequence. When the WiX engine applies every MSI file it apparently passes ARPSYSTEMCOMPONENT="1" which prevents the MSI entry from appearing in Windows "Add/Remove Program" control panel but I actually want each MSI in the chain to appear there.
<Chain>
<MsiPackage SourceFile="myproduct_1.0.0.0.msi"</MsiPackage>
</Chain>
This is the log entry:
[01A4:0A94][2013-11-05T18:04:07]i301: Applying execute package: myproduct_1.0.0.0.msi, action: Install, path: C:\ProgramData\Package Cache\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}v1.0.0.0\myproduct_1.0.0.0.msi, arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7"
How can I stop this from happening?
Set the Visible attribute on the MsiPackage element to "yes".

CustomAction error with IIS : UnauthorizedAccessException

I get the following exception when I double click my MSI package
CustomActionException: System.UnauthorizedAccessException: Filename: redirection.config
Error: Cannot read configuration file due to insufficient permissions
at Microsoft.Web.Administration.Interop.AppHostWritableAdminManager.GetAdminSection(String bstrSectionName, String bstrSectionPath)
at Microsoft.Web.Administration.Configuration.GetSectionInternal(ConfigurationSection section, String sectionPath, String locationPath)
at Microsoft.Web.Administration.ServerManager.get_SitesSection()
at Microsoft.Web.Administration.ServerManager.get_Sites()
...
It does this because it's trying to access the path C:\Windows\System32\inetsrv\config from inside a Custom Action
Now if I ran the MSI from PowerShell, where you're running as Administrator, it seems to work fine but the default double-click invocation does not work
Other than adding myself to the UAC of that folder, is there anyway for my CustomActions to run with elevated privileges?
I tried the Package-level attribute of InstallPrivileges="elevated" but to no effect
You need to use Bootstrapper to run the msi in admin mode by default. You can use Wix Bootstrapper to do that. Or you can use any third party tool like WinZip Self extractor or Inno Setup to run the msi file. It will run the msi as administrator always.

wix: ICE57 and ICE91 warnings for perUser installer

I'm using wix 3.5 to author a windows installer with the "perUser" install scope. The wxs file is here, the resulting MSI file is here.
I get the following strange warnings from the light.exe linker. I'm not sure if I should just suppress them or if there is some better way to fix this.
ICE57
D:\hg\downmarker\setup\product.wxs(34)
: warning LGHT1076 : ICE57: Component
'component.downmarker.exe' has both
per-user and per-machine data with an
HKCU Registry KeyPath.
This warning doesn't make sense to me, because the installer works fine without administrative access - which AFAIK proves that the installer doesn't write any "per-machine data" as the warning claims.
ICE91
D:\hg\downmarker\setup\product.wxs(37)
: warning LGHT1076 : ICE91: The file
'downmarker.exe' will be installed to
the per user directory
'DownMarkerFolder' that doesn't vary
based on ALLUSERS value. This file
won't be copied to each user's profile
even if a per machine installation is
desired.
This warning doesn't make sense to me either because I explicitly mark the installer as having the "perUser" install scope.
ICE57 is shown because component "component.downmarker.exe" contains registry entries from HKEY_CURRENT_USER and HKEY_CLASSES_ROOT. HKEY_CLASSES_ROOT is per-machine, so the component has both per-user and per-machine data.
I noticed you are using HKEY_CLASSES_ROOT for a file association. You can use "HKEY_CURRENT_USER\SOFTWARE\Classes" instead to obtain a per-user file association.
ICE91 is harmless and can be ignored for per-user installations:
http://msdn.microsoft.com/en-us/library/aa369053(VS.85).aspx