0
votes

I have a program that is composed of 4 different setup libraries. What I would like to do is completely compartmentalize these libraries so that I can easily reuse them or limit the functionality of the program based on what gets installed. Currently, all of my custom actions are declared inside the installer itself. I would like to have these custom actions reside in their respective setup libraries as well as specify them in the installexecutesequence. Is this something that is possible with WiX? So far, this is what I have tried to no avail.

Project A SetupLibrary

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Fragment>
    <?if $(var.Platform) = x86?>*See note
        <CustomAction Id="MyCustomAction" FileKey="Somefile.exe" Execute="deferred" ExeCommand="CmdLineArgs" Return="check"/>
        <InstallExecuteSequence>
            <Custom Action="MyCustomAction" After="StartServices"/>
        </InstallExecuteSequence>
    <?endif ?>
    </Fragment>
</Wix>

*I have this condition to prevent this custom action from generating twice in my main project since I import both the 32 bit and 64bit version of this setup library.

Using this above method, my project compiles just fine, but the custom action is nowhere to be found in the Custom Actions table of the MSI upon compilation. If I explicitly list the custom action inside the InstallExecuteSequence inside my installer, it works, however that defeats my end goal of having all these components wrapped up in their own setup libraries.

2

2 Answers

0
votes

No, you always have to add some sort of authoring under the Product element to pull in declarations from anywhere else, including a Fragment even in the same file. In this case the authoring would be the InstallExecuteSequence/Custom/@Action reference.

There are at least three ways to avoid putting the text of that element directly into your setup project code:

  1. a preprocessor <?include ../ProjectA/libraryA.wxi ?>, which would necessitate an absolute or relative path
  2. a custom element, implemented in an extension
  3. a merge module reference

An extension seems like overkill. I'd use an include if I could.

0
votes

If you wanted to separate this out to be used in non-WiX installs you could build it into a merge module.