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
Related
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.
I'm new with WiX, and I'm trying to have my Bootstrapper launch my installed application when it completes. To accomplish this, I'm using
<Variable Name="LaunchTarget" Value="path_to_exe"/>
However, it is not easy for me to get the path to the executable. The reason for this is because I'm using <Chain> to install some pre-requisites and then an msi that actually installs my exe.
So to do this, the msi is writting the path to a known location in the registry, and then the bootstrapper reads it and uses it.
The problem is that when the bootstrapper reads the registry, the msi hasn't run yet, so it is unable to run the executable at the end.
Here's my WiX, if it helps:
<?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 Installation" UpgradeCode="a8964402-f3fc-4878-aafd-31ecda6b685e" Version="1.0.0.0">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
<bal:WixStandardBootstrapperApplication LicenseFile="EULA.rtf"
ThemeFile="theme.xml"
SuppressOptionsUI="yes" />
</BootstrapperApplicationRef>
<Chain>
<PackageGroupRef Id="NetFx40Redist"/>
<ExePackage Id="OpenSSL" SourceFile="pre-requesite.exe" />
<MsiPackage Id="myInstall" SourceFile="mySetup.msi" />
</Chain>
<util:RegistrySearch Root="HKLM"
Key="Software\myProgram"
Value="myEXEPath"
Variable="myEXEPath"
Result="value"
Format="raw" />
<Variable Name="LaunchTarget" Value="[myEXEPath]"/>
</Bundle>
</Wix>
So, in short, I'm trying to have the RegistrySearch run AFTER the MsiPackage installs. Can this be done? If not, what alternatives do I have?
As I side note, if I manually fill in the registry value before installation, everything works fine. This means that besides the order things are running in, everything is working fine.
RegistrySearches run during the Detect operation. Custom BAs could run Detect after Apply, but that's not really an option since you're using the WixStandardBootstrapperApplication.
Lucky for you, WiX v3.9 added support for running the LaunchTarget already elevated, with the requirement that the path to the target .exe be in the registry under HKLM. So you would do this:
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
<bal:WixStandardBootstrapperApplication LicenseFile="EULA.rtf"
ThemeFile="theme.xml"
SuppressOptionsUI="yes"
LaunchTargetElevatedId="MyAEEId" />
</BootstrapperApplicationRef>
<ApprovedExeForElevation Id="MyAEEId"
Key="Software\myProgram" Value="myEXEPath" />
Edit:
It looks like you are required to set LaunchTarget as well. Why doesn't your bundle know where it will be? You can just put in gibberish for LaunchTarget (WixStdBA will try the registry location first), but can't you use built-in variables and/or MsiProperty elements to locate the exe?
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
Question: Can we access msi files (and other installers) packed with Burn Bootstrapper at install time?
Let's say if we need to read some property, or apply mst just before starting the installation etc.
Is that possible?
Did you try to add the transform as a payload to your MsiPackage element, and set the TRANSFORMS property using MsiProperty element?
<MsiPackage ...>
<Payload Compressed="yes" SourceFile="c:\mytransform.mst"/>
<MsiProperty Name="TRANSFORMS" Value="mytransform.mst" />
</MsiPackage>
If you really need to get the path to embeded payloads, and if you are using the standard bootstrapper, you are going to need to create a bafunctions.dll and do some C/C++ coding.
To create a bafunctions.dll, first download the wix source code and use the project src\burn\samples\bafunctions as an example. To use the bafunctions.dll you have compiled, add it as a payload to the bootstrapper
<BootstrapperApplicationRef ...>
<Payload Compressed="yes" SourceFile="c:\bafunctions.dll" />
</BootstrapperApplicationRef>
That's enough to make the standard bootstrapper call the bafunctions.dll callbacks. You have callbacks for OnDetect(), OnDetectComplete(), OnPlan(), OnPlanComplete(). You can use these functions to do some non-trivial detections and get/set burn variables.
This post has an example on how to use bafunctions.dll to get the path to an embeded payload at runtime:
How to pass the path to a bundle's payload to an msi?
I'm using an rtflicence standard bootstrapper to install dotnet before my poject msi in a chain.
I noticed that there's an 'options' button which displays an install location dialog and allows the user to change the default installation directory.
I need to either:
Prevent this options button from being displayed, or
Populate the install location with a default path, and pass this back to the installer should the user change it.
I read that it's possible to pass Burn variables to msipackages from bootstrapper but I haven't found any further details and would appreciate being pointed in the right direction.
Thanks
To go with option 1, you'd have to roll your own BootstrapperApplication and remove the options button from the menu.
Option two is significantly easier to implement. The bootstrapper uses a special Burn variable called InstallFolder to get and set what is in the text block on that view, which you can assign inside the Bundle element.
<Variable Name="InstallFolder" Type="string" Value="[ProgramFilesFolder]"/>
The constant ProgramFilesFolder will set the value of that text block when the program starts, and if the user browses to a different directory, it will be stored in that same variable. To pass it to the MSI, in your chain, you pass the InstallFolder using the MsiProperty tag (INSTALLLOCATION is the name of the property in your WiX project).
<MsiPackage Vital="yes" DisplayName="Your Name" Id="MsiId" SourceFile="path/to/file.msi">
<MsiProperty Name="INSTALLLOCATION" Value="[InstallFolder]" />
</MsiPackage>
I just discovered the SuppressOptionsUI option that addresses your Option 1 without rolling your own BootstrapperApplication:
<?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>
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
<bal:WixStandardBootstrapperApplication LicenseFile="..\eula.rtf" SuppressOptionsUI="yes"/>
</BootstrapperApplicationRef>
<Chain>
</Chain>
</Bundle>
</Wix>
I think you can try removing the options button by creating a theme. I haven't had to use themes myself but here are two related SO links that may get you pointed in that direction:
WiX bootstrapper theme file?
Theme for my WiX Installer