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

[Edwin Castro]

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
>