Closed bevanweiss closed 3 months ago
This breaks down when an extension has more than one custom action---which is very common with needing different custom actions for install and uninstall. $(sys.BUILDARCHSHORT)
is one solution to the suffix. Otherwise, it's down to documentation when you're at the lower level of messing around with scheduling.
User story
As a setup developer, I shouldn't need to open the WiX source code (or even know that it exists) to successfully configure the sequencing of CustomAction items with regards to each other.
Proposal
Preface: I've got no idea how the backend logics of this could work.
As a setup developer, I will often encounter a situation where I need to schedule actions related to other actions. I likely don't even know what are/are not custom actions.
An example of how I would like to naively author a particular custom action (SetProperty) against another custom action (RemoveFolderEx).
Instead I currently get this error:
So that would be the ideal situation... if an ID is specified, we just look at the element, hopefully identify the Custom Action associated with it, and substitute it in. We should ideally be able to match the Sequence itself (i.e. UI, Execute) also. If there's multipart custom actions, and we care about which one is referenced, then perhaps if it's not specified it would throw up an error, and prompting the setup author... e.g.
would produce an error "Custom Action Sequencing of "AfterSteve" was scheduled After "CreateSteve", however "CreateSteve" is a multipart execution, did you mean "CreateSteve:ConfigureUsers", "CreateSteve:AddUser", or "CreateSteve:RemoveUser"?
This comes up, because I've just been tripped up with it, and going through the build cycle each time was painful to finally work out that my lowercase x86 apparently wasn't a match for the uppercase X86 that it was wanting. And that was already after me knowing:
Considerations
Lots of issues... Many extensions will have several custom actions used to represent one authored element, e.g. util:User may do nothing if it's not under a Component, otherwise it has a ConfigureUsers CA, and AddUsers, and RemoveUsers which are scheduled in different phases of the installation. What might the setup author mean when they say 'Before="CreateUserSteve"', would it mean before the ConfigureUsers? Perhaps.. since maybe they want to set things up before any user activity occurs. After="CreateUserSteve" probably means after the AddUsers (but maybe it could mean after the RemoveUsers.. which is all the way in the Commit phase..).