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.
Related
How do I specify the source of a file based on where the installer I am running is located. Say for example that I want to place a few files from the folder of the installer(that is for instance located on the desktop or in downloaded files) into a specified path in C/programfiles.
<ComponentGroup Id="ProgramFilesFolder_files" Directory="INSTALLFOLDER">
<Component Id="Program.exe" Guid="d0c868d9-4d5b-41f0-9ce8-d655ac80ee7c">
<File Id="Program.exe" Name="Program.exe" Source="???" />
How do I set the source property?
Have i understood it right that I am supposed to set the source to:
Source="..\Program.exe"
Does this refer to where the MSI file is run from. If I for example put my installer file along with the files I need the source for. Will I be able to use the code above as a relative path that changes when I move the installer. So I can run the installer from elsewhere, with the only requierment that the installer is in the same folder as the files I want to program the source for?
I have an open source project that makes authoring WiX installers easier. One of it's features is relative file paths. You can read about it here.
https://github.com/iswix-llc/iswix-tutorials
Essentially the project templates use an XPI called SourceDir to create an abstraction for where to find the source files. This is relative to the WXS file. The GUI tool uses the location of the WXS and the SourceDir to enumerate the source structure for drag / drop operations and then uses it to author the File elements like such.
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<?define ComponentRules="OneToOne"?>
<!-- SourceDir instructs IsWiX the location of the directory that contains files for this merge module -->
<?define SourceDir="..\Deploy"?>
<Module Id="DesktopApplicationMM" Language="1033" Version="1.0.0.0">
<Package Id="04cfbb1b-8105-4f3e-9b7a-c1d5354dc670" Manufacturer="DesktopApplicationMM" InstallerVersion="200" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="DesktopFolder" />
<Directory Id="MergeRedirectFolder">
<Component Id="owc17DECDE7A34AF545285829FF09EF24AE" Guid="4791fdfe-28ff-3c07-2f9e-e2f418c712f8">
<File Id="owf17DECDE7A34AF545285829FF09EF24AE" Source="$(var.SourceDir)\DesktopApplication.exe" KeyPath="yes">
<Shortcut Id="sc06A337B51AED2DF7E22F894A213D2792" Name="Desktop Application" Directory="DesktopFolder" />
</File>
</Component>
</Directory>
</Directory>
<ComponentGroupRef Id="Custom" />
</Module>
</Wix>
If you ever refactor where the files come from you only have one line to update.
I've been asked to jump on a project and help build an installer. I'm normally a hardware guy so my coding experience is limited, especially when it comes to this particular instance.
Essentially I have a bunch of components: exe's, dll's, drivers, etc. that I would like to bundle together into one installer to deliver to the client. A coworker suggested using the Wix toolset to do this.
Most of the material I have found has only covered the very basics and it seems like I'm being asked to do something custom and a bit more nuanced. Any help in the form of some guidance on the most efficient/easiest way to do this would be a huge help. A rough outline of what I'll need to do and/or any examples would go a long way.
Thanks!
If you want to send a bundle of files, you can simply mention those specific files in Product.wxs file of wix setup project .
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<Component Id="abc.exe" Guid="de34d0c6-3b9e-439c-a254-c9f695e2e389">
<File Id="abc.exe" Name="abc.exe" Source="$(var.abc_TargetDir)abc.exe" />
</Component>
<Component Id="abc.exe.config" Guid="3a38ad30-51ce-42fd-b262-1249c7087111">
<File Id="abc.exe.config" Name="abc.exe.config" Source="$(var.abc_TargetDir)abc.exe.config" />
</Component>
</Fragment>
Like the above abc.exe and the .config file, any other file can be sent using the component tag inside the ComponentGroup tag.
Can anyone confirm that heat works only on DLLs, OCX, maybe some other files, but not on executable files?
The thing is, that I run heat on my COM components DLLs or OCXs (registered through regasm, regsvr32) and it harvests all data in the registry related to the file. However, I have DCOM servers that have lots of info related to themselves in the registry (self registered using /regserver) and the harvesting tool extracts just a minimal information about the file itself but nothing from registry related to the file, NOTHING. Like the resulted wxs file could be something like this:
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<DirectoryRef Id="INSTALLFOLDER">
<Component Id="ohserver.exe" Guid="{E8D87743-45B6-459E-A72F-22D9A0D5CE16}">
<File Id="ohserver.exe" KeyPath="yes" Source="SourceDir\ohserver.exe" />
</Component>
</DirectoryRef>
</Fragment>
</Wix>
As you see nothing from registry, CLSIDs, ProgIDs, RegistryValues, etc.
That's correct. Heat does not support harvest self-reg data from .exe servers.
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 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.