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

[Rob Mensching]

They are used by heat to "mutate" output (one of the pieces of the convoluted processes heat runs). They aren't related to the Compiler. To extend the Compiler you just need a compiler extension.

Short replies here. Complete answers here: https://www.firegiant.com/services/


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

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
>

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