Sorry, either mark as deferred and schedule between InstallInitialize and InstallFinalize, or mark as immediate and schedule after InstallFinalize. If you try to schedule a deferred action after InstallFinalize I believe you'll get a runtime error.
If you use an immediate action after InstallFinalize your action cannot cause the install to roll back (because the transaction has already been committed). -- Mike Dimmick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frédéric Viollet Sent: 24 July 2007 09:35 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] customactions and installsequence Ok, thanks a lot for your explanation. So if I correctly understood what you said, I must declare my custom action as deferred. So I guess I write it this way: <CustomAction Id='ConfigureHttpConf' BinaryKey='apmwsinst.dll' DllEntry='apm_edit_conf' Execute='deferred' Return='check' /> <InstallExecuteSequence> <Custom Action='ConfigureHttpConf' After='InstallFiles'>NOT Installed</Custom> </InstallExecuteSequence> Is the "After='InstallFiles'" still correct? Thanks again? Mike Dimmick a écrit : > In effect, Windows Installer makes two passes over the actions in between > InstallInitialize and InstallFinalize. In the first pass, by the client > process that called MsiDoAction (which is msiexec.exe if you just ran an > .msi from Explorer), the installer writes out a script for the tasks each > standard action and *deferred* custom action must perform, but it doesn't > actually do them yet. Any *immediate* custom actions are, as the name > indicates, executed immediately when encountered. > > The script generated is then handed off to the Windows Installer service > when the InstallFinalize action is encountered in the execute sequence. It's > this script which actually installs the files. > > If you want to modify a file you're installing, you'll need a deferred > custom action. This has the limitation that it cannot read the original > database, only a special custom action data property which has the same name > as the custom action, plus a few other properties (only the script is passed > across to the Windows Installer service). The pattern that WiX uses is an > immediate custom action that appears in the execute sequence, which reads > tables to work out what to do, then schedules one or more deferred custom > actions to actually do the work (passing the commands in the custom action > data for the deferred actions). > > If you do this, be sure to set the Modified and Created timestamps to the > same value, otherwise when you come to apply an upgrade, Windows Installer > will think that the user has modified the file and will not overwrite it. > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
