[wix-users] Extracting temporary helper binaries for data driven custom actions and clean up

[John Cooper]

Well, it all depends what you want, as usual.  In my case, on a rollback, I want the database deployment file trees to remain so I can figure out what went wrong.  However, in a successful install, I want them removed.

If you want them remove in all failure cases, then a rollback action is what you want.

Yes, Commit actions are a variety of deferred and use CustomActionData.  I pass my trees into the commit action in this manner and it loops over them to delete them.  You would need to do something similar for Rollback.  Either that, or you could use a semi-automatic custom action pattern and add rows to RemoveFiles.

--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.® | Lenexa, KS  66214 | Ext:  431050 |JoCooper at jackhenry.com



-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Edwin Castro
Sent: Friday, December 4, 2015 4:33 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Extracting temporary helper binaries for data driven custom actions and clean up

The e-mail below is from an external source.  Please do not open attachments or click links from an unknown or suspicious origin.

I'm hearing that rollback actions still need to be responsible for cleanup, correct?

How do you communicate to the commit action which resources to cleanup? Do commit actions use CustomActionData? Should they be scheduled by the schedule action after the execute action?

--
Edwin G. Castro

On Fri, Dec 4, 2015 at 2:27 PM, John Cooper <JoCooper at jackhenry.com> wrote:

> I use commit actions to clean up my database deployment custom 
> actions.  I maintain a list of trees (one for each database and one 
> for the deployment binaries).  On success, the commit action goes 
> through the trees and deletes all of them.  All of my trees are rooted 
> in the installing users TEMP directory--this makes sure I have access/permissions to remove.
> Generally, Commit actions run on install success.
>
> --
> John Merryweather Cooper
> Senior Software Engineer | Integration Development Group | Enterprise 
> Notification Service Jack Henry & Associates, Inc.® | Lenexa, KS  
> 66214 | Ext:  431050 | JoCooper at jackhenry.com
>
>
>
> -----Original Message-----
> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On 
> Behalf Of Edwin Castro
> Sent: Friday, December 4, 2015 4:24 PM
> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> Subject: [wix-users] Extracting temporary helper binaries for data 
> driven custom actions and clean up
>
> The e-mail below is from an external source.  Please do not open 
> attachments or click links from an unknown or suspicious origin.
>
> I'm planning a class of data driven custom actions that will require 
> to extract binaries from the Binary table to use in the execute and 
> rollback actions. Those binaries will need to be deleted from the 
> target system when the installation completes successfully or after rollback.
>
> The way I'm handling this right now is to extract the binary streams 
> from the Binary table in the schedule action and write them to the 
> execute custom action data *AND* rollback custom action data BEFORE 
> any other per-item data. In this approach the execute and rollback 
> actions are responsible for writing the helper binaries to disk and 
> clean up after themselves.
>
> I initially used the approach because it got me to a working state quicker.
> Now I have an opportunity to clean up the custom actions but I'm not 
> sure how to proceed. Currently I'm considering using commit actions to 
> help clean up after myself but I don't fully understand how they work 
> or how they are intended to be used.
>
> My current plan:
>
> 1. Schedule action extracts binaries from Binary table and writes them 
> to disk at a temporary location.
> 2. Schedule action writes paths to temporary locations to execute and 
> rollback custom action data.
> 3. Execute action reads temporary paths and uses helper binaries but 
> does NOT delete the files yet (even on failure)!
> 4. Rollback action can use helper binaries on failure because the 
> execute action did not delete the files.
> 5. Rollback action is responsible for deleting helper binaries.
> 6. Commit action is responsible for deleting helper binaries after 
> successful completion???
>
> Does this approach even make sense?
>
> When should commit actions be scheduled in relation to other custom 
> actions?
>
> Does the commit action execute even after a rollback? Does this imply 
> that I can do all clean up in the commit action regardless of whether 
> we rolled back or not?
>
> Am I missing something fundamental about commit actions that would 
> change the way I'm thinking about this plan?
>
> --
> Edwin G. Castro
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant 
> http://www.firegiant.com/
>
> NOTICE: This electronic mail message and any files transmitted with it 
> are intended exclusively for the individual or entity to which it is 
> addressed. The message, together with any attachment, may contain 
> confidential and/or privileged information.
> Any unauthorized review, use, printing, saving, copying, disclosure or 
> distribution is strictly prohibited. If you have received this message 
> in error, please immediately advise the sender by reply email and 
> delete all copies.
>
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant 
> http://www.firegiant.com/
>

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.