Wix v3.10 Boostrapper crashes on Windows 7 RTM - wix

On a 32 or 64 bit Windows 7 Pro (just RTM no updates), I create a bundle with the WiX Toolset (Visual Studio WIX Bootstrapper project) v3.10.0.1823 that outputs an executable.
If I install SP1, the bootstrapper works as intended.
If I install the custom MSI with my application (without dependencies) it works on RTM.
This was in the application event log:
Windows cannot access the file for one of the following reasons: there is a problem with the network connection, the disk that the file is stored on, or the storage drivers installed on this computer; or the disk is missing. Windows closed the program because of this error.
Program:
File:
The error value is listed in the Additional Data section.
User Action
1. Open the file again. This situation might be a temporary problem that corrects itself when the program runs again.
2. If the file still cannot be accessed and
- It is on the network, your network administrator should verify that there is not a problem with the network and that the server can be contacted.
- It is on a removable disk, for example, a floppy disk or CD-ROM, verify that the disk is fully inserted into the computer.
3. Check and repair the file system by running CHKDSK. To run CHKDSK, click Start, click Run, type CMD, and then click OK. At the command prompt, type CHKDSK /F, and then press ENTER.
4. If the problem persists, restore the file from a backup copy.
5. Determine whether other files on the same disk can be opened. If not, the disk might be damaged. If it is a hard disk, contact your administrator or computer hardware vendor for further assistance.
Additional Data
Error value: 00000000
Disk type: 0
Any thoughts on how I can the bootstrapper running on blank install of Windows 7 RTM?
Update:
Tried an empty Bootstrapper just referencing the package (MSI) for my application. I can run the package for my application just fine standalone, just can't launch thru the bootstrap:
Is there a log file or something I can look at to provide more info? To get around this, I'm going to try creating a MSI that does an OS check (requiring SP1 of Win 7) that wraps the Bootstrapper.exe.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Name="Bootstrapper1" Version="1.0.0.0" Manufacturer="Me" UpgradeCode="d94220ca-b99f-4d1d-acec-024cfc65c898">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<MsiPackage Id="MyPackage" SourceFile="<path to my package>" Name="MyPackage" Cache="no" Compressed="yes" Permanent="yes" Vital="yes" DisplayInternalUI="no" InstallCondition="VersionNT" Visible ="yes" />
</Chain>
</Bundle>

Works for me. I created a WiX Bootstrapper Project in a new solution in VS2015, built it, and was able to install and uninstall it on a Win7 x64 Pro RTM VM with no updates.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Name="Bootstrapper1" Version="1.0.0.0" Manufacturer="Me" UpgradeCode="ff6c5879-f9b6-4941-a769-3c51bca2a070">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<MsiPackage Id="NetFx451Redist" SourceFile="path\to\testing.msi" />
</Chain>
</Bundle>

Related

WiX standard bootstrapper: launch application after install

I am creating a Bundle installer, using WiX standard bootstrapper in order to install .NET Framework 4.5 (if not yet installed) and my application in the user's computer. The bundle installer also allows the user to set the installation path for the application, and uses WiX standard bootstrapper's UI only (no other installers' interfaces are shown to the user).
Right now I'm struggling to allow the user to launch my application at the end of the installation.
Closest related anwers I could find use a variable named LaunchTarget, which causes WiX standard bootstrapper to display a "Launch" button in the end of the installation.
Given solutions and why I wasn't able to use them follow:
Answer "A" suggests setting the LaunchTarget variable to the exact folder inside "Program Files" folder where the application should be installed. This doesn't work for me, because I want to allow the user to specify the target installation folder (application can be installed outside of the "Program Files" folder).
Answer "B" suggests setting the LaunchTarget variable by using the InstallFolder variable to determine where the user configured the standard bootstrapper to install the software to. This seemed perfect for my case, but after setting the LaunchTarget value simply to "[InstallFolder]" I verified that pressing the "Launch" button in the standard bootstrapper's UI actually opens the folder where the installer is running, and not the folder where the user chose to install the software, as I expected. (is that a bug?)
Question is: how can I correctly set the LaunchTarget variable to the right path, considering that the user can modify the installation folder through WiX standard bootstrapper's UI?
The code for the Bunde follows.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Name="My Game Trainer" Manufacturer="MY_MANUFACTURER_ID_HERE" UpgradeCode="MY_GUID_HERE" Version="!(bind.packageVersion.TrainerMsiPackage)" DisableModify="yes">
<Variable Name="LaunchTarget" Value="[InstallFolder]" />
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLargeLicense">
<bal:WixStandardBootstrapperApplication ShowVersion="yes" LicenseFile="PATH_TO_MY_LICENSE.rtf" />
</BootstrapperApplicationRef>
<Chain>
<PackageGroupRef Id="NetFx45Web"/>
<MsiPackage Id="TrainerMsiPackage" SourceFile="$(var.SetupMSI.TargetPath)" DisplayInternalUI="no">
<MsiProperty Name="TRAINER_INSTALL_DIR" Value="[InstallFolder]"/>
</MsiPackage>
</Chain>
</Bundle>
</Wix>
Using WiX Toolset v3.11.1 (+Visual Studio 2017 Extension).

Create a Single MSI installer

I have developed a application which is in a 32-bit and 64-bit format. These applications require corresponding registry entries as well. I am delivering these as separate packages for 32-bit and 64-bit using WiX.
Now my requirement is to create a single installer which installs the components based on OS configuration. I tried using Bootstrapper to bundle my packages.
My bootstrapper code looks as below:
<Bundle Name="Bootstrapper" Version="1.0.0.0" Manufacturer="MYCOMPANY" UpgradeCode="b24f74ca-883c-4572-9479-37d92d733aa0">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<ExePackage Id="source1" Compressed="yes" PerMachine="yes" SourceFile="32\Sample.exe" InstallCondition="Not VersionNT64" />
<ExePackage Id="source2" Compressed="yes" PerMachine="yes" SourceFile="64\Sample.exe" InstallCondition="VersionNT64" />
</Chain>
</Bundle>
My bootstrapper output is MSI. When I run the MSI I am getting MainEngineThread is returning 1620 in the verbose log.
Please suggest how can I bundle two EXE's to get single MSI package.
Error 1620 isn't particularly nasty - it just means it can't open the MSI file, and the simplest explanation for that is that your directory structure is incorrect and the exe is calling the MSI install with the incorrect location or name for the MSI file.

WIX Bundle "This installation package could not be opened."

Alright, so I've been working with the WIX installer and I'm working on building a bundle for bootstrapping the .NET framework. After a lot of reading the official material I've had issues with getting any bundle to start. I finally decided to strip it down to the minimum to try to figure out what's wrong. Here's my code:
<?xml version="1.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Version="1.0.0.0" UpgradeCode="{0e0055fe-ce30-4b84-8b98-6a73128ff93d}">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense"/>
<Chain>
<MsiPackage Id="NewPackage" SourceFile="C:\TestInstall.msi"/>
</Chain>
</Bundle>
</Wix>
It builds successfully, but when I run it I get the message "This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package."
I'm guessing I'm missing some basic piece, but for the life of me I can't figure out what it is. What else do I need to add for the created MSI to run properly?
EDIT: Found the answer. Visual Studio 2012 doesn't compile Bundles properly with WIX 3.6.

How to include prerequisites with msi/Setup.exe in WIX

I'm trying to combine my package in a single setup EXE file and upload it to the Internet.
I have created a Microsoft bootstrapper that contains Setup.exe with project MSI output, and pre-requisite .NET Framework 2.0, Windows Installer 3.1 , Visual C++ 2005 redistributables, and Microsoft ReportViewer. I have created a setup project using Visual Studio 2008.
Now I'm trying to create a single compressed setup using WiX 3.6. I have installed it in Visual Studio 2008.
I have attached the setup.exe and MSI file using following commands.
<ExePackage SourceFile ="setup.exe" Compressed ="yes"/>
<MsiPackage SourceFile ="myproject.msi" Compressed ="yes" />
But it is unable to find the MSI file. How can I include the above prerequisites with it?
Or can I download the above prerequisites from the Internet while installing? How do I do it?
I have removed the default setup.exe from Visual Studio and used the MSI file and dependencies from Visual Studio to create a WiX 3.6 Bootstrapper:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<Bundle Name="My Application"
Version="1.0"
IconSourceFile ="E:\logo.ico"
Manufacturer="My company"
UpgradeCode="4dcab09d-baba-4837-a913-1206e4c2e743">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
<bal:WixStandardBootstrapperApplication
LicenseFile="E:\License.rtf"
SuppressOptionsUI ="yes"
LogoFile ="logo.ico" />
</BootstrapperApplicationRef>
<Chain>
<ExePackage
SourceFile ="ReportViewer\ReportViewer.exe"
Compressed ="yes"
Vital ="no"
Permanent ="yes"/>
<ExePackage
SourceFile ="vcredist_x86\vcredist_x86.exe"
Compressed ="yes"
Vital ="no"
Permanent ="yes"/>
<MsiPackage
SourceFile ="MySetup.msi"
Compressed ="yes"
DisplayName ="My Application"
ForcePerMachine ="yes"/>
</Chain>
</Bundle>
</Wix>
It compresses into an single EXE file with prerequisites.
SourceFile will accept a relative path the .msi file. Or, if you are building the .msi file with a WiX Setup project, you can add a reference to the Setup project in the WiX Bootstrapper project. That defines variables you can use like this:
<MsiPackage SourceFile ="$(var.myproject.TargetPath)" Compressed ="yes" />
Your users will probably have a better experience if you drop the Visual Studio Bootstrapper and put all prerequisites in the WiX Bootstrapper. It'll be a little more work for you because there isn't a pre-defined ExePackageGroup or ExePackage for all of your project's prerequisites.
The best place to check for information on what should go into an ExePackage definition is the documentation for the particular prerequisite in question. But, it is also instructive to compare with the Visual Studio Bootstrapper packages (in, e.g., C:\Program Files\Microsoft Visual Studio 9\SDK\v2.0\Bootstrapper\Packages) and similar prerequisites that might be predefined in the WiX source code. In particular, in the WiX source code, you will find an ExePackage that downloads .NET 4 from the Internet if needed while installing.
You can include some pre-requisite file with something like:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="MyApplication" Version="$(var.ProductVersion)" Manufacturer="manuf" Language="1033">
[...]
<Directory Id="ANOTHERLOCATION" Name="MyApplicationName">
<Component Id="ApplicationFiles" Guid="12345678-1234-1234-1235-111111111111">
<File Id="ApplicationFile4" Source="C:\Users\user\Desktop\requisite.exe"/>
<CreateFolder />
</Component>
</Directory>
<SetDirectory Id="ANOTHERLOCATION" Value="[WindowsVolume]MyApp" />
<Feature Id="DefaultFeature" Level="1">
<ComponentRef Id="ApplicationFiles" />
</Feature>
</Product>
</Wix>
The above copies the requisite.exe file inside C:/MyApp.
You then have to run the requisite.exe file from your program based on some conditions.
This is the most basic and straight-forward way without using complicated Wix wizardry.
You can use something like NSIS to wrap up your bootstrapper and MSI. You'll need to write a simple NSIS script, like this:
!define PRODUCT_NAME "YourProductNameHere"
Name "${PRODUCT_NAME}"
OutFile "SetupWrapper.exe"
Icon "Setup.ico"
BrandingText " "
SilentInstall silent
Section
SetOutPath "$TEMP\${PRODUCT_NAME}"
; Add all files that your installer needs here
File "setup.exe"
File "product.msi"
ExecWait "$TEMP\${PRODUCT_NAME}\setup.exe"
RMDir /r /REBOOTOK "$TEMP\${PRODUCT_NAME}"
SectionEnd
Save this to a file named SetupWrapper.nsi, and edit the product name and paths to setup.exe and your MSI file. Now you can build this file to get a single EXE file that contains the bootstrapper and the MSI.
When this EXE is run, it will not have any UI of its own -- it will simply extract your bootstrapper and MSI to a temp folder, then execute the bootstrapper, and clean up afterwards.
You can also add a post-build step to your project to build this wrapper, which will automatically generate the combined wrapper EXE. To do this, you can add a command like this:
path-to-NSIS\nsis-2.46\makensis.exe /V2 your-project-path\SetupWrapper.nsi

RemotePayload: The system cannot find the file '' with type ''

Moving to WiX 3.6, I'm trying to make use of burn features to ease potential download/install of required pieces, such as a specific VC++ runtime.
I started small with just some "test.wxs", see below, which is OK for candle.exe:
$ candle test.wxs
Windows Installer Xml Compiler version 3.6.3303.0
Copyright (C) Outercurve Foundation. All rights reserved.
test.wxs
But light.exe chokes on it:
$ light test.wixobj -ext WixBalExtension
Windows Installer Xml Linker version 3.6.3303.0
Copyright (C) Outercurve Foundation. All rights reserved.
light.exe : error LGHT0103 : The system cannot find the file '' with type ''.
Could someone help with this (rather cryptic) error message?
It seems related to RemotePayload, since a modified version with local file works correctly. However, I'd like to save on package size and leave the downloading on the target machine if so needed.
Full content of "test.wxs" was:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Version="1.0.0.0"
UpgradeCode="e349236d-6638-48c5-8d8b-db47682b9aeb">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<!-- C++ Runtime -->
<ExePackage Name="vcredist_x64.exe"
DownloadUrl="http://www.microsoft.com/en-us/download/confirmation.aspx?id=2092" >
<RemotePayload CertificatePublicKey="F321408E7C51F8544B98E517D76A8334052E26E8"
CertificateThumbprint="D57FAC60F1A8D34877AEB350E83F46F6EFC9E5F1"
Description="Microsoft Visual C++ 2008 Redistributable Setup"
Hash="13674C43652B941DAFD2049989AFCE63CB7C517B"
ProductName="Microsoft Visual C++ 2008 Redistributable"
Size="4961800"
Version="9.0.30729.17" />
</ExePackage>
</Chain>
</Bundle>
</Wix>
Partial answer to my own question:
The error message disappears if I add the attribute Compressed="no" to the ExePackage element.
Documentation about "Compressed" attribute says: "Whether the package payload should be embedded in a container or left as an external payload" and its value can be "yes", "no", or "default".
Using "yes" or "default" triggers the error message. Using "no" doesn't.
I had the same trouble with another package (the .NET framework) and Wix 3.7. I used the Wix source code to find the appropriate package names and registry keys to test, and then pasted the relevant bits into my installer. Then, I intentionally set 'Compressed="yes"' because I wanted to embed the file in my installer instead of having it downloaded.
There was a report similar to yours posted in this mailing list thread:
Benjamin Mayrargue: If an ExePackage has a DownloadUrl and Compressed is set to yes, light failed with error LGHT0103: The system cannot find the file '' with type ''.
Markus Wehrle: Ok, I see. If you want to have the ExePackage compressed into your bootstrapper.exe (compressed="yes") you need to specify it using "Source" attribute. Cause it will be compressed into your boostrapper during compile time, you must not declare a DownloadUrl. If you specifiy compressed="no" your ExePackage gets downloaded from the DownloadUrl during the installation of your boostrapper.
Rob Mensching: More specifically, you cannot use RemotePayload element and Compressed='yes' on the ExePackage element together. That doesn't make sense and the bug here is that the compiler didn't give you an error message here saying that.
So yes, you've correctly identified the same fix to the problem.
The Compressed attribute, by the way, specifies 'Whether the package payload should be embedded in a container or left as an external payload.' That external payload can either be a RemotePayload or another file on the disk, but the typical setup is a single bootloader with all the resources embedded into it.
Using yes for the Compression attribute will allow your application and the VC++ runtime to be installed even if the user has a slow or nonexistent Internet connection. Remove the DownloadUrl and RemotePayload from your installer, and replace them with just Compressed="yes" like this:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Version="1.0.0.0"
UpgradeCode="e349236d-6638-48c5-8d8b-db47682b9aeb">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<!-- C++ Runtime -->
<ExePackage Name="vcredist_x64.exe"
Compressed="yes">
</ExePackage>
</Chain>
</Bundle>
</Wix>
Then download the vcredist_x64.exe file (yourself, once) and place it adjacent to your test.wxs file. Adjust 'Name' if you want it in a different location. Note that this will increase the size of your resulting bootstrapper by about the size of vcredist_x64.exe, so it's not a good idea if your users will be downloading your installer.
In my case the error was thrown because the filename/directory path was over 255 characters. The file exist yet the compiler is stating that the file doesn't exist.