How to resolve BootstrapperApplicationRef in Wix Toolset 3.11? - wix

I get error messages related to my BootstrapperApplicationRef which I do not understand as these come from examples based on the well known wix book and also this example. Maybe it is because I use version 3.11 of the toolset (the book is based on 3.6)? My installer needs to install some software to download.
Here is my wxs:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Name="Awesome Software"
Version="1.0.0.0"
Manufacturer="Awesome Company"
UpgradeCode="c352f5c7-1dbe-416c-820d-685b058270d5">
<BootstrapperApplicationRef
Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<ExePackage Id="DymoLabelSoftware"
SourceFile="DLS8Setup.8.5.1.exe"
DownloadUrl="http://download.dymo.com/dymo/Software/Win/DLS8Setup.8.5.1.exe" />
</Chain>
</Bundle>
</Wix>
Compiling results in the following error message:
Unresolved reference to symbol
'WixBootstrapperApplication:WixStandardBootstrapperApplication.RtfLicense'
Changing this element as described here, results in the following message:
Unresolved reference to symbol
'WixBootstrapperApplication:WixNetFxExtension'
Removing the BootstrapperApplicationRef results in another error message:
Unresolved reference to symbol
'WixBootstrapperApplication:WixNetFxExtension'
I can understand that something is unresolved but the found examples to resolve it simply do not work. How can I fix this? How to resolve this reference without getting an error message?
Update 1
I tried to make this work with a bootstrapper project instead. That partially solved my problem.
I just get another error message.
The system cannot find the file 'DLS8Setup.8.5.1.exe'.
This is really strange. The compiler should not try to find it at compile time. It is something to be downloaded at runtime.
I tried making this work by adding a dummy DLS8Setup.8.5.1.exe.
However, when looking up my result in my bin\Debug folder, I get an application that, when double clicking, does not show a user interface. This approach does not really solve my problems, it changes my problem.
It just want to have an installer that shows some user interface when starting and does execute a download. That's all.
Update 2
Using the other example to download just give other errors too.

So here's working sample based on your updates:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Name="DLS8SetupBootstrapper" Version="1.0.0.0" Manufacturer="me" UpgradeCode="ada71964-11c8-4877-9544-f72fe65579c0">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<ExePackage Id="DymoLabelSoftware"
Name="DLS8Setup.8.5.1.exe"
Compressed="no"
DownloadUrl="http://download.dymo.com/dymo/Software/Win/DLS8Setup.8.5.1.exe">
<RemotePayload Description="MyRemoteApp" ProductName="DLS8Setup.8.5.1.exe" Size="119087088" Version="8.5.1.0" Hash="204ecb5296290527418693f3a464b59a8801808f"/>
</ExePackage>
</Chain>
</Bundle>
</Wix>
Note that you need to know size in bytes and sha1 hash of your file. Also "Name" is important attribute.
To check hash I used this resource
Haven't found how to get size online so here's C# sample:
var sizeInBytes = new FileInfo("D:\\DLS8Setup.8.5.1.exe").Length;
So just update that variables for your file and you'll get your installer.
P.S. It will show that DLS8Setup installer GUI. If you need do it silent it will depend on every installer. As I get you want to use your own, not that one from example, so I can't do anything without your file.

Related

WiX Bundle bal:condition - util:RegistrySearch - Not working

A similar post is up here but I cant get mine working
WiX Bundle bal:condition - util:RegistrySearch variable always false
Sir, I am struggling get this exact thing working. "Version" is set to 0 when Registry key is absent and to 1 when key is present. Either cases my bundle still gets installed.
I am using VS 2015 and Wix 3.10. Pls can you help.
<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 Name="XXX"
Version="XXX"
Manufacturer="XXX"
UpgradeCode="XXX"
IconSourceFile="XXX"
Copyright="XXX" >
<util:RegistrySearchRef Id='SearchForMyIns' />
<BootstrapperApplicationRef Id="ManagedBootstrapperApplicationHost">
...
</BootstrapperApplicationRef>
<Chain>
<PackageGroupRef Id='NetFx40Web' />
<MsiPackage SourceFile="$(var.DummyInstaller.TargetDir)\DummyInstaller.msi" DisplayName="Dummy Conditioning" />
</Chain>
</Bundle>
<Fragment>
<util:RegistrySearch
Id='SearchForMyInst'
Variable="Version"
Result="exists"
Root="HKLM"
Key="SOFTWARE\MyInst"
Win64="yes" />
<bal:Condition Message="ThirdParty Application Required.">Version</bal:Condition>
</Fragment>
</Wix>
The Bal:Condition doesn't evaluate if you are using MBA. Check the following link
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-Burn-Bundle-condition-does-not-work-if-using-MBA-td7581757.html
Change
<BootstrapperApplicationRef Id="ManagedBootstrapperApplicationHost">
to
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
You will see Bal:Condition working
The reason this is always installing for you is that
<bal:Condition Message="messagehere">Version</bal:Condition>
will evaluate the existance of Version not the value of Version. Since your registry search is on exists, Version is always defined and thus the condition always passes. (I believe this is because all registry search variables are implicitly string variables)
If you add "Version = 1" then your installation should only continue when your registry search does find what you're looking for.
I would also like to point out a particularly nasty pitfall of this type of condition. What happens if a user installs your bundle then decides they don't need your bundle or the third party program anymore and they uninstall them both but they uninstall the third party program first?
Your installer will be unable to uninstall because when it tries to run it will fail the bal:Condition every time since the third party program is no longer present on the system.
To solve this behaviour you should add "OR WixBundleInstalled" to your bal:Condition.

Wix Toolset - Variable Shared Across Projects/Solution

I am trying to share a variable across 2 of my wix projects but I am having issues.
Basically I am trying to accomplish having the version number of my bootstrapper and MSI in one file and then this referenced by the two projects.
I have three projects
Install - This is a setup project that creates an .msi file
Bootstrapper - This is a Wix Bootstrapper project that references and runs the .msi file at runtime
Shared - This is a wixlib project that contains a single variable in a fragment that is the version number
The shared project contains a single file i have called GlobalVars.wxs and looks like this
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<?define VersionNo = "6.86.123"?>
</Fragment>
</Wix>
The bootstrapper references this variable like this
<Bundle Name="ProgramName" Version="$(var.VersionNo)" Manufacturer="CompanyName" UpgradeCode="Guid" Compressed="no">
and the Install project references the variable like this - and has a reference to the .wxs from the shared project
<Product Id="*" Name="Program Name" Language="2057" Version="$(var.VersionNo)" Manufacturer="CompanyName" UpgradeCode="guid">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" InstallPrivileges="elevated"/>
<?include GlobalVars.wxs ?>
Both projects have references setup to the wixlib project that contains the variable
When i attempt to build I am getting this error on both the install and bootstrapper project
Undefined preprocessor variable '$(var.VersionNo)'.
If the <?include?> tag resolved the issue I would expect the install project to build
Does anyone have any ideas as to what I might be doing wrong here?
To me it looks like the variable has not been defined by the time the build attempts to call it, but I am unsure as to show to change the order to ensure the variable is defined before anything else
Thanks for the help
I believe the answer to this question will help. I've used it and noticed that properties seem to be usable in my main wxs file.
To summarise, you need to set up a fake componentGroup in your library fragment, and use it in your installer. You do not need the include anymore, as long as the fake componentGroup from your fragment is referenced as a componentGroupRef in your main install, and your wixlib project is referenced in your installer project through VS (you said you'd already done this in your comments above).
Your library fragment might look something like this.
<Fragment id="fragment_id_may_not_be_needed">
<?define VersionNo = "6.86.123"?>
<ComponentGroup Id="c.define_version_num" />
</Fragment>
If the define for whatever reason doesn't work, try using a property instead. I'd be interested to know which works. Properties seem to work for me.
Then reference it in your main install like this:
<Feature Id="Main_installation" Title="Main installation" Level="1">
<!-- bringing in fragments from the shared libraries -->
<ComponentGroupRef Id="c.define_version_num" />
</feature>
Give it a whirl.

Generating an EXE from MSI in Wix

I'm tring to generate EXE file from MSI in Wix installer, I added a new project (Bootstrapper) but I can specifying the path of my MSI file
<Bundle Name="Bootstrapper" Version="1.0.0.0" Manufacturer="" UpgradeCode="e45fdbb6-192c-46f7-b4db-d04af69edada">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<!-- TODO: Define the list of chained packages. -->
<MsiPackage SourceFile="WixSetup.msi" />
</Chain>
</Bundle>
Can you help ?
Thanks in advance
Abdulsalam
Add a reference of your msi's wixproj to your bootstrapper application.
You can now reference the msi file like this
<MsiPackage SourceFile="$(var.WixProjName.TargetPath)" />
This will automatically point to the debug location or release location depending on your build mode.
You can see a list of well-defined vars passed to candle.exe in the output when building. You'll see a bunch of defines like "-dWixProjName.Property=Value" and then you can use those values in your bundle xml like so $(var.WixProjName.Property) which will get replaced by the Value before compiling.
You can see a list of the defined properties when you reference another project here: http://wixtoolset.org/documentation/manual/v3/votive/votive_project_references.html

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.

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.