Adam Langley wrote:

Because my custom action is actually modifying the target system (installing reports), I need to make it a 'deferred' custom action.


Right.

That means that it won't necessarily execute within the confines of the MSI, hence the custom action may not be able to get a reference to the database to read the information it needs.


To really explain it I need a whiteboard.<g> Basically, the execute sequence is broken up into phases. The first is script-generation, when immediate custom actions run and determine the actions -- and their data. Then the script is run; that's when you have very limited access to the database and the installer session it's running in. It's also when CAs get elevated, so they can modify per-machine data.

There's also rollback, when MSI unwinds the script and deletes files, puts back overwritten ones, etc. That's why deferred CAs need "matching" rollback CAs, to undo what they did.

And there's commit, but let's not go there.<g>

Am I on the right track?


Exactly!

--
sig://boB
http://joyofsetup.com/

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
WiX-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs

Reply via email to