Sorry, that bit wasn't very clear. My understanding is that
InstallInitialize begins a batch. InstallExecute executes that batch and
begins a new batch, but still within the transaction - I presume you'd use
it if for some reason you had a custom action that you couldn't make
deferred but which needed to see the results of the deferred actions so far.
I can't think of a good example! InstallExecuteAgain basically exists
because you can only schedule a given action once, so it's a second
opportunity to execute the batch and begin a new one. Finally,
InstallFinalize executes the script and ends the transaction - anything
after InstallFinalize executes immediately and failure will not roll back
the transaction.
The rollback script still builds up after an InstallExecute, so if something
fails even after that point, all the actions back to InstallInitialize are
undone.
It does depend on what the custom action does. Custom actions that merely
read the state of the system and set properties accordingly should probably
run before the transaction, either in the UI sequence or early in the
execute sequence. Deferred custom actions are limited to only being able to
read their own custom action data (properties named the same as the CA)
presumably because only this data is actually copied into the script; if
they need any other information, that needs to be copied into the deferred
CA's custom action data.
This is how the WiX CAs work: there is an immediate custom action scheduled
between InstallInitialize and InstallFinalize for a given feature (for
example, in the case of <SqlDatabase>, <SqlScript> and <SqlString>, the
ConfigureSql custom action). This CA reads the SqlDatabases, SqlScripts and
SqlStrings tables, works out which components are being installed (or
removed!) and therefore which scripts and strings to run, and in turn
schedules the deferred custom actions that perform those tasks and undo
them. If there are any <SqlDatabase> elements it schedules the
CreateDatabase and RollbackCreateDatabase actions, and for any SqlScripts or
SqlStrings it schedules ExecuteSqlStrings and RollbackExecuteSqlStrings. As
before, a CA can only be scheduled once, so all of the SQL string text (for
example) is concatenated together with an unusual separator character to
form the custom action data for these deferred actions.
--
Mike Dimmick
_____
From: Aaron Feng [mailto:[EMAIL PROTECTED]
Sent: 13 May 2007 22:59
To: Mike Dimmick
Cc: Rob Mensching; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Ignore Custom Action on Repair
Mike,
Thanks for the great explanation. Now I understand what Rob was talking
about before now, it all makes sense.
Just for clarity, action script is created in between InstallInitialize and
InstallFinalize in InstallExecuteSequence table. Does the action script
only contain actions that lives in between InstallInitialize and
InstallFinalize or even contains the actions after InstallFinalize ?
When the action script is passed to the Windows Installer service it
executes the action script when InstallExecute, InstallExecuteAgain, and
InstallFinalize actions are executed. Does each of these action (
InstallExecute, InstallExecuteAgain, and InstallFinalize) execute the whole
action script or just part of it? If part of it, how does it know which one
to execute in the action script?
So for example, if I have an action (in the action script too) that runs an
external executable, if it fails it will cause the msi to run the roll back
script. I assume it doesn't actually roll back anything on this particular
action since it doesn't know about the external executable.
Basically, if I understand correctly, if I want to run a custom action I
need to put it some where in between InstallInitialize and InstallFinalize
in the InstallExecuteSequence table or should it live some where else?
Thanks again,
Aaron
On 5/13/07, Mike Dimmick <[EMAIL PROTECTED]> wrote:
Windows Installer does things in three (possibly two) distinct phases:
- UI sequence
- Install execute sequence
- Script execution
Normally (unless set to Basic or No UI) execution begins with the UI
sequence. The actions listed in the UI sequence are performed in order -
normally just presenting dialogs to modify options and any necessary custom
actions to gather system state data - until the ExecuteAction action is
reached. This causes the InstallExecuteSequence to be processed (for an
INSTALL action)
If Basic or No UI are used, the UI sequence is ignored and the execute
sequence runs directly. This is why it's sometimes necessary to put custom
actions which set properties in both sequences.
The execute sequence is then executed. At the point that the
InstallInitialize action is executed, Windows Installer starts writing a
script. The actions listed in the execute sequence are processed and the
actual file copy/registry write/etc actions are written to the action
script, and the necessary information to undo those operations are written
to the rollback script. The batched-up script is passed to the Windows
Installer service when the InstallExecute, InstallExecuteAgain, and
InstallFinalize actions are executed. If an error occurs in action script
execution, the rollback script is executed and the installation aborts.
Almost all actions between InstallInitialize and InstallFinalize are
scripted; immediate custom actions are performed immediately, however, while
deferred custom actions are written into the script (along with their custom
action data) and actually executed in the correct position relative to the
effects of the other actions.
The UI sequence and execute sequence are processed in the client process
(shown in the logs with (c)) while the script is processed by the service
process (shown as (s)).
The part of the execution sequence between InstallInitialize and
InstallFinalize is what Rob's referring to as the transaction, because if an
operation fails for whatever reason, the changes are rolled back. Also, only
one Windows Installer package can be running in this region at a time.
It's recommended that all actions that change the state of the system are
performed as part of the transaction, i.e. that any custom actions that
change system state are deferred and execute between InstallInitialize and
InstallFinalize.
--
Mike Dimmick
_____
From: [EMAIL PROTECTED] [mailto:
<mailto:[EMAIL PROTECTED]>
[EMAIL PROTECTED] On Behalf Of Aaron Feng
Sent: 13 May 2007 16:49
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Ignore Custom Action on Repair
Rob,
I'm not sure if we are both on the same page. Please choose to ignore me if
I sound like I'm smoking crack. :) By no means am I a msi expert, but I
would like to understand best practices in a certain situation. I can
provide extra context if it would help.
Ignore everything I have said so far in this thread because I will explain
the situation from the beginning to avoid any confusion.
In our installer we pack an encryption tool with our application. The
purpose of this encryption tool is to allow clients to encrypt or decrypt
their configuration files. The configuration files should be encrypted at
all times when the app is running (This is part of the business
requirement). The reason the tool is deployed as part of the msi package
it's because in some situations the client may want to temporary decrypt and
encrypt the files for debugging purposes.
With that said, I would like the configuration files to be automatically
encrypted during the installation process. Currently I'm running a custom
action with ExeCommand to achieve this. It works fine, except I noticed, it
would try to run the custom action during repair. I only want this custom
action to run during the initial install. I tried various condition around
the custom action such as NOT Installed, didn't seem to work for me.
I'm not tied down to any specific solution, just want to under best solution
for this problem. If what I'm doing is completely hacky and should be
avoid, I will understand.
In your first reply you said the following:
After InstallFinalize? That isn't part of the transaction.
What do you mean it's not part of the transaction?
Thanx,
Aaron
On 5/12/07, Rob Mensching <[EMAIL PROTECTED]> wrote:
Don't try to do what you are doing. I don't have enough context to provide
any better suggestions than that.
From: Aaron Feng [mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
]
Sent: Saturday, May 12, 2007 10:42 AM
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Ignore Custom Action on Repair
I would also like to avoid any trickery. Do you have any suggestions for
alternatives?
Thanx,
Aaron
On 5/12/07, Rob Mensching < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:
Note, this sort of design is generally very fragile and I always encourage
people to rethink their need for this sort of trickiery during setup.
-----Original Message-----
From: Aaron Feng [mailto:[EMAIL PROTECTED]
Sent: Friday, May 11, 2007 4:49 PM
To: Rob Mensching; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Ignore Custom Action on Repair
I have a custom action that runs a tool during install. I do not want
this tool to run during repair, in fact I only want this custom action
to run only during the inital install. Currently it will attempt to
run the custom action during repair which causes an error from the
tool.
Aaron
On 5/11/07, Rob Mensching < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:
>
>
>
>
> After InstallFinalize? That isn't part of the transaction. What are you
> trying to accomplish?
>
>
>
>
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ] On Behalf
> Of Aaron Feng
> Sent: Friday, May 11, 2007 2:31 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Ignore Custom Action on Repair
>
>
>
>
> I run a custom action during install which works fine, but I don't want to
> run it during repair. I tried every possible way, but no luck. Here is
an
> example what I'm doing:
>
> <InstallExecuteSequence>
>
> <Custom Action="MyAction1" After="InstallFinalize">
> <![CDATA[(&MyFeature1=3) AND (NOT Installed)]]>
> </Custom>
>
> <Custom Action="MyAction2" After="InstallFinalize">
> <![CDATA[(&MyFeature2=3)) AND (NOT Installed)]]>
> </Custom>
>
> </InstallExecuteSequence>
>
> Thanx,
>
> Aaron
-------------------------------------------------------------------------
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-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
