[wix-users] changing install location of MSI packages within Bundles

Phill Hogland phill.hogland at rimage.com
Fri Jun 17 10:55:07 PDT 2016


Here are some examples of passing a target path from a Bundle to a MSI
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Passing-Location-from-Bootstrapper-to-MSI-td7583617.html

http://stackoverflow.com/questions/13085051/how-do-i-pass-a-default-install-location-to-the-rtflicense-bootstrapper

In both of the above cases the Variable/@Value (default initialize) is tied to a Built-In Burn variable, and is not a hard coded path as you have used.  I recommend that you also use a Burn Built-in 'root' variable.  Since your statement "should go to their default locations in %PROGRAMFILES% or %PROGRAMFILES(X86)% as appropriate" implies that you are supporting both x64 and x86 packages, you should define at least two of these variables.  for example I also ship bundles with mixed platforms which target both embedded machines and remote clients.

My Bundle has a Variable defined for my x64/x8x driver like this
 <Variable Name="Install6432Folder" Type="string" Value="[ProgramFiles6432Folder]Company" bal:Overridable="yes" Persisted='yes' />
And another Burn Variable for my 32 bit apps:
 <Variable Name="InstallFolder" Type="string" Value="[ProgramFilesFolder]Company" bal:Overridable="yes" Persisted='yes' />

Now each MSI has a folder tree built off of the above root path.  The above links describe how the MSI's directory tree better than I can.  Because the bal:Overrideable is defined that means that your BA can modify the path to pretty much anything that makes sense in your security context.  So in your BA you can detect that you want your 32 bit MSI to be installed at "C:\Pretend\Plugins" you then call code to write "C:\Pretend\Plugins" to the Burn Engine Variable "InstallFolder".  If you have two of the three packages which are 32 bit packages, then both of them go to relative paths from "C:\Pretend\Plugins" based on the directory tree of the MSI.

If you want the x64/x86 MSI package to also go to "C:\Pretend\Plugins", then also call the function to set the Install6432Folder variable  "C:\Pretend\Plugins".

If want to specify the full path for each MSI (and not have relative subfolders in the MSI) then define a separate variable for each MSI, default to a Burn  Built-in 'root' variable, then in your BA code coerce each path to the full path that you ultimately want.

WixStdBA has an option to allow the user to modify an InstallFolder 'path', IIRC.  (I rarely us it.)   I believe you can modify that, but generally you would either add a BAfunctions.dll to the WixStdBA, or implement your own custom BA to code up the additional behavior that you need.

https://wixextba.codeplex.com/

The above link has lots of examples for using a BAFunctions.dll, and there is also a sample project in the Wix sorce under the Burn\Samples folder.  Also in the wix source the Setup\WixBA is the custom BA used to install the toolset.  While not a tutorial it is useful to study it.

So:
1) Upgrade wix to v3.10.3. v3.10.2 has a known problems. No sense in fighting them.
2) define your Burn Variables using a Built-in Burn root folder wth bal:Overrideable (and Presisted)
3) Implement code to modify the multiple (if different but unrelated paths are expected) Burn Variable based on your  detect code, and write that change back to Burn prior to call Engine.Apply()

I'm supposed to be in bed fighting off a virus cold, so double check any code above as my memory is foggy.
________________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of John Naylor <mejohnnaylor at mac.com>
Sent: Friday, June 17, 2016 11:06:22 AM
To: wix-users at lists.wixtoolset.org
Subject: [wix-users] changing install location of MSI packages within Bundles

I have a package that can be installed onto 2 types of machine:
1) ordinary windows PC
2) a turnkey that runs embedded windows

In the 2nd case I need to install a bundle of 3 MSI’s into a specific folder, while in the first, they should go to their default locations in %PROGRAMFILES% or %PROGRAMFILES(X86)% as appropriate.

It seems that the trick to this is to use an MsiProperty within each MsiPackage in the bundle to set the INSTALLLOCATION Property from a Burn Variable. Simple enough if I could get it to work. I can use a registry search to determine whether the install is on a regular machine or a turnkey, and set the variable appropriately. Unfortunately, it’s not working.

Here’s my test bundle code, the SampleFirst.msi package, when installed by itself, installs to %PROGRAMFILES(X86)%. Unfortunately, it installs to the same place when installed from the Bundle (FoobarBundle.exe).

I’m testing this on a regular windows 10 machine. The aforementioned Turnkey system isn’t involved at this point.

<?xml version="1.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi <http://schemas.microsoft.com/wix/2006/wi>"
                xmlns:bal="http://schemas.microsoft.com/wix/BalExtension <http://schemas.microsoft.com/wix/BalExtension>"
        >
 <Bundle Version='0.1.0' UpgradeCode=‘GUID HERE'>
   <BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" >
        <bal:WixStandardBootstrapperApplication
                LicenseFile="License.rtf"
        />
   </BootstrapperApplicationRef>
                <Variable Name="MyInstallFolder" Type="string" Value="C:\Pretend\Plugins" bal:Overridable="yes"/>
   <Chain>
        <MsiPackage Id="SampleFirst" SourceFile="SampleFirst.msi" Vital="yes" Visible="yes" >
                <MsiProperty Name="INSTALLLOCATION" Value="[MyInstallFolder]" />
        </MsiPackage >
   </Chain>
 </Bundle>
</Wix>

I’m building the Bundle using these commands:

> candle FoobarBundle.wxs -ext WixBalExtension
> light FoobarBundle.wixobj -ext WixBalExtension

This is with version 3.10.2.2516 of the toolset.

Thanks in advance for your help!

John

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/



More information about the wix-users mailing list