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.
Related
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.
We use a wixlib that has all the dialogs (most of which can be shared with other products on our portfolio).
One of these dialogs will show a EULA. This EULA is added to the wixlib project as (RTF) content (Build Action: Content, Copy to output: DontNotCopy)
Now next to showing the EULA, I must also install it with all the products.
Can I some how reference the EULA that (has to be?) is embedded in the wixlib?
Or do I need to copy this file to all the wixproj of all products? Given it's a EULA, which won't change that much, it's still a hassle if it does change. I trying to avoid that.
I'm guessing, I need to copy it to all products, but I wanted to double check.
In hindsight, I overthought this. I simply added the file to a component in the wixlib project which can be referenced from the consuming Wix project.
In the wixlib:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<Component Id="C_General_EULA" Directory="INSTALLFOLDER" Guid="{INSERT_GUID}" KeyPath="yes">
<File Id="F_General_EULA" Source="Localization\EULA_en-us.rtf"/>
</Component>
</Fragment>
</Wix>
In the consuming Wix project:
<Feature Id="EULAFeature" Level="1" Display="hidden">
<ComponentRef Id="C_General_EULA"/>
</Feature>
Again, in hindsight really simple.
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
I'm building a Wix installer and I need two separate versions of said installer. One that picks up the latest development build of the project and one that picks up the latest release build. Currently my fragment looks like this:
<Property Id="Program.ReleaseBuild" Value="0" />
<?define ReleaseBuild = [Program.ReleaseBuild]?>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="InstallFolder">
<Component Id="TheExe" Guid="GUID_GOES_HERE">
<?if $(var.ReleaseBuild) = 1?>
<File Id="ProjectExe" Source="(Rel Project Path)/program.exe" />
<?else?>
<File Id="ProjectExe" Source="(Dev Project Path)/program.exe" />
<?endif?>
</Component>
</ComponentGroup>
</Fragment>
And I have a transform on the msi that transforms the file after build. But the problem is that the file is picked up on compile time not install time, so both version of the installer end up having the same file contained in them. Any idea how I can conditionally grab a dev file or a rel file in the same wix project?
If you want to create installation packages based on build quality (debug versus release), you can use two product configuration and select the source based on it. This way, you can run msbuild twice, one for each configuration. I don't understand the purpose of the transform you mentioned.
So here are steps you could take to accomplish this:
Create an empty solution.
Add your wixproj to it.
Add your csproj to it.
Add a reference of the csproj to the wixproj.
Modify your File[Source] to use the project reference, this way:
<File Source="$(var.MyProject.TargetPath)" Id="ProjectExe" />
The $(var.MyProject.TargetPath) will automatically get the exe from the correct path.
Create a batch file to run the msbuild twice, one for each configuration, with the following commands:
C:\> msbuild mySolution.sln /p:Configuration=Debug
C:\> msbuild mySolution.sln /p:Configuration=Release
The result will be two installation packages, one for each configuration.
I want to install a product with some dll with Wix 3.5.
These dll are determined during the msi installation through a radio buttons group.
I have :
a (fragment) wxs for myDllv1
a (fragment) wxs for myDllv2
a (UI fragment) wxs with the RadioButtonGroup to choose between myDll v1 and myDll v2 with a property INSTALLTYPE
a main wxs file which installs the correct version of myDll.
Problem : I have another set of dll to add and I want to modify as less files as possible.
I don't want to introduce bugs and I want to keep things decoupled.
I would like to modify only the UI fragment with the radio buttons and add a myDllv3 fragment (without doing any changes to my main wxs file, so no condition in that file..).
Is it possible?
Why don't you use pre-processors to select the correct fragments when building the msi?
<?if $(env.SomeBuildParameter) = SetA ?>
<?include myDllSetAv1.wxs ?>
<?include myDllSetAv2.wxs ?>
<?else ?>
<?include myDllSetBv1.wxs ?>
<?include myDllSetBv2.wxs ?>
<?endif ?>
I may be misunderstanding the question, but it sounds like your different set of Dlls should be grouped by features within WIX. I'd suggest creating independent WIX fragments that represents a feature for each of your set of Dlls and then you can tie your UI to install a specific feature as appropriate.
You represent a feature at the product level like so:
<Feature Id="Feature.One" Title="Feature One">
<ComponentGroupRef Id="FeatureOneDlls.Group" />
</Feature>
<Feature Id="Feature.Two" Title="Feature Two">
<ComponentGroupRef Id="FeatureTwoDlls.Group" />
</Feature>
And within each of the features I'd recommend using a separate wxs file to supply the fragment information that contains the files for that feature.