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

[Edwin Castro]

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/extensions.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
>>
>