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