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:
[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]
*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]> 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]> wrote:
>
>
>
>
> After InstallFinalize? That isn't part of the transaction. What are
you
> trying to accomplish?
>
>
>
>
> From: [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
