I am trying to run a custom action as a first step of my MSI. I want my MSI to run the custom action before anything else. We have a custom.exe which does some cleanup prior to the installation. Can someone please tell me what would be my Install Exec Sequence & Condition be?
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


ok, so looks like it works pretty well if i set my Install Exec Sequence to run After LaunchCondition

Install Exec Sequence> After LaunchCondition
Install Exec Condition> REMOVE=ALL
Answered 07/18/2011 by: chichora123
Fourth Degree Green Belt

Please log in to comment
if it is modifying the system as I expect it is based on the name.

It should be scheduled early as possible in the deferred phase. Although it is bad practice to do it in the immediate phase you can get away with it in Corporate land because the installing user will always be an admin account.

I would advise against it if you can help it. By running during the immediate phase you are basically stating the installation will only complete for an admin user.
Answered 07/18/2011 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
Are you really sure it has to be run right at the start of the Install Execute sequence? (Eg, Before the evaluation of Launch Conditions, AppSearch etc) I'm pretty sure if the custom.exe is just removing a few files/registry/other junk then you should be fine scheduling it immediately after InstallInitialize, and Deferred in a system context.

" cleanup prior to the installation"
If that's the case, your condition should be:
Not Installed
Answered 07/19/2011 by: captain_planet
Fifth Degree Brown Belt

Please log in to comment
My thoughts more or less exactly. What does the CA do that the RemoveFile and RemoveRegistry tables can't do?
Answered 07/19/2011 by: VBScab
Red Belt

Please log in to comment
the golden rule of packaging if you modifys the system in any way the CA "MUST" be deferred.

this is because you only have access to the system context on the installer service during this time. If you attempt to run this during the immediate phase you are implicitly saying you will inherit the user context of the initiating user.

this in turn means it will fail if the initiating user is a non admin.

vbscab is spot on as always it would be better to use native tables where suitable.
Answered 07/19/2011 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment