[wix-devs] Instantiate a Set of Related Standard Elements Multiple Times

Rob Mensching rob at firegiant.com
Tue Apr 14 08:26:57 PDT 2020

That's a very reasonable question and I think wix-users is the place since writing a custom WiX Extension is not developing the WiX Toolset itself.


  Rob Mensching
 FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Edwin Castro via wix-devs
Sent: Monday, April 13, 2020 5:03 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Edwin Castro <egcastr at gmail.com>
Subject: Re: [wix-devs] Instantiate a Set of Related Standard Elements Multiple Times

Is it more appropriate to ask this in wix-dev?

Edwin G. Castro

On Mon, Apr 13, 2020 at 4:57 PM Edwin Castro <egcastr at gmail.com> wrote:

> What are mutator extensions?
> https://wixtoolset.org/documentation/manual/v3/wixdev/extensions/exten
> sions.html
>  says
> Mutator extensions allow clients to modify the behavior of the Mutator.
> That description is vague enough to not actually provide any clues to 
> the uninitiated on what exactly they do.
> --
> Edwin G. Castro
> On Mon, Apr 13, 2020 at 4:21 PM Edwin Castro <egcastr at gmail.com> wrote:
>> I'm considering writing a custom compiler (?) extension that would 
>> provide a custom element that represents a small set of related 
>> custom actions. The purpose of the custom element and extension is to 
>> make it easy to author / use this set of related custom actions. As a 
>> result, ideally, I'd just like to produce the same output that 
>> parsing the standard elements would produce without needing to generate that output myself.
>> Conceptually, I'd like to write something like
>> <ext:MyCustomElement Id="..." Attrib1="..." Attrib2="..." ... />
>> and have it "expand" to the equivalent of
>> <CustomAction Id="..." ... />
>> <CustomAction Id="..." ... />
>> <CustomAction Id="..." ... />
>> <!-- etc -->
>> The custom actions are related and must be instantiated as a group 
>> once per instance of the custom element because they need to be 
>> scheduled at different locations in InstallExecuteSequence. In other 
>> words, I don't think I can use table-driven custom actions because I 
>> can't process these bits at the same logical place in the InstallExecuteSequence.
>> It is analogous to scheduling a bunch of WixSilentExec custom actions 
>> with their associated properties and custom action data. Each 
>> instance produces a number of standard elements that go together but 
>> cannot be aggregated into a table to be processed at one time.
>> Currently I'm thinking of using a wxi, <?define?>, and <?include?> 
>> but that's less than ideal. An extension seems like more work but 
>> could potentially result is something that is much easier to use and 
>> less error prone. I'm just not very familiar with what wixobj output 
>> various standard elements need to produce so I am hoping there's a 
>> way that I could parse my element and generate some temporary objects 
>> (or something similar) that can produce the correct output for me.
>> For example, ParseSetPropertyElement and ParseCustomActionElement are 
>> private and consume an XmlElement. What I'd like to do is get the 
>> equivalent of the functionality of ParseSetPropertyElement and 
>> ParseCustomActionElement (the wixobj output they produce) by 
>> instantiating those elements at compile-time. Hmm... not sure I'm 
>> describing what I'd like to do well enough. I suppose what I was 
>> hoping for was something very similar to <macrodef> in ant. I 
>> understand that <macrodef> doesn't exist in WiX today but I was hoping I could emulate it in C# in an extension.
>> --
>> Edwin G. Castro
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/

More information about the wix-devs mailing list