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

[Bob Arnson]

A compiler extension generates output (rows in WiX v3), not source code. So you'd have to do the same kind of thing that ParseSetPropertyElement does.

If you actually want to get WixSilentExec custom actions, then forget what I said because it's a bad idea. 😊

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

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/