17

I was looking for list of actions and their sequence when running a WiX setup. Somehow the official website doesn't seem to provide any information.

The basic problem is that I want to schedule my custom actions correctly. Typically I need to register a DLL with regsvr32.exe, and this can only be done once the files are copied to the harddrive. However the custom action 

<Custom Action="RegisterShellExt" After="InstallFiles">

failed with the error message "file not found".

What I've done then is analizing the log of my MSI with WiX Edit, and I've found that the Action InstallFiles exists more than once. And effectively the files are written only the second time it appears. So I changed my custom action to the following :

<Custom Action="RegisterShellExt" Before="InstallFinalize">

Here is the sequence I've extracted from the logs of my MSI: 

Action start 15:16:49: INSTALL.
Action start 15:16:49: PrepareDlg.
Action start 15:16:49: AppSearch.
Action start 15:16:49: LaunchConditions.
Action start 15:16:49: ValidateProductID.
Action start 15:16:49: DIRCA_NEWRETARGETABLEPROPERTY1.5D429292039C46FCA3253E37B4DA262A.
Action start 15:16:50: CostInitialize.
Action start 15:16:50: FileCost.
Action start 15:16:50: CostFinalize.
Action start 15:16:50: WelcomeDlg.
Action 15:16:51: LicenseAgreementDlg. Dialog created
Action 15:16:53: CustomizeDlg. Dialog created
Action 15:16:55: VerifyReadyDlg. Dialog created
Action start 15:16:56: ProgressDlg.
Action start 15:16:56: ExecuteAction.
Action start 15:16:58: INSTALL.
Action start 15:16:58: AppSearch.
Action start 15:16:58: LaunchConditions.
Action start 15:16:58: ValidateProductID.
Action start 15:16:58: CostInitialize.
Action start 15:16:59: FileCost.
Action start 15:16:59: CostFinalize.
Action start 15:16:59: InstallValidate.
Action start 15:17:00: InstallInitialize.
Action start 15:17:08: ProcessComponents.
Action 15:17:09: GenerateScript. Generating script operations for action:
Action ended 15:17:09: ProcessComponents. Return value 1.
Action start 15:17:09: UnpublishFeatures.
Action start 15:17:09: RemoveShortcuts.
Action start 15:17:09: RemoveFiles.
Action start 15:17:09: InstallFiles.
Action start 15:17:10: CreateShortcuts.
Action start 15:17:10: RegisterUser.
Action start 15:17:10: RegisterProduct.
Action start 15:17:10: PublishFeatures.
Action start 15:17:10: PublishProduct.
Action start 15:17:10: ConfigureInstaller.
Action start 15:17:10: InstallFinalize.
Action 15:17:10: ProcessComponents. Updating component registration
Action 15:17:12: InstallFiles. Copying new files
Action 15:17:21: CreateShortcuts. Creating shortcuts
Action 15:17:21: RegisterProduct. Registering product
Action 15:17:23: ConfigureInstaller. [[note: CustomAction]]
Action 15:17:22: PublishFeatures. Publishing Product Features
Begin CustomAction 'ConfigureInstaller'
Action 15:17:28: RollbackCleanup. Removing backup files
Action ended 15:17:28: InstallFinalize. Return value 1.
Action start 15:17:28: RegisterShellExt. [[note: CustomAction]]
Action ended 15:17:33: INSTALL. Return value 1.
Action start 15:17:35: ExitDialog.

Does anyone know an official listing?

Damian Vogel
  • 1,050
  • 1
  • 13
  • 19

2 Answers2

14

The short answer - you should make you custom action deferred and schedule after InstallFiles (if it relies on installed file, which I think it does).

The long answer - you should get acquainted with in-script execution term. Read more about it on MSDN. When you see the InstallFiles the first time in the log file, it's when immediate actions run and deferred actions are written and scheduled to the installation script. The second time is when it actually executes (and installs files). If you make your action deferred, you'll see the same behavior for it in the log file.

This might sound not very clear, but it can't until you read more about the way it is designed to work.

Yan Sklyarenko
  • 31,557
  • 24
  • 104
  • 139
  • thanks! for the moment I'll stick to the short answer :) actually, the answer is quite clear to me. first they prepare the tasks, however if you make it immediate it will not wait until the actual work starts. – Damian Vogel Feb 14 '11 at 09:00
  • 1
    But is there an offical listing of the sequence of actions? Otherwise we just have to trial and error which seems ridiculous?! – markmnl May 16 '16 at 07:28
5

For registering DLLs, it is best to avoid self-registration.

We use the HEAT command to generate a WiX fragment which does the registration for us.

Use 

heat file myfile.dll -o myfile.wxs

The advantage of this is that the registry entries are installed and removed correctly and there are no problems with whether the file has been installed or not at the time the registration is done.

AntonyW
  • 2,284
  • 16
  • 21
  • thanks for the input. I didn't know that there is a special script to register dlls. for the moment I'll keep the custom action, but as soon as the rest of my installer works fine I'll see how get the heat command work. – Damian Vogel Feb 14 '11 at 09:03
  • I was trying to use the heat utility, but I can't get past that HEAT5150 warning. I guess as a consequence of this warning, the resulting wxs file doesn't contain any useful code, only the `Directory` and the `Component` fragment. here is the full warning message: `heat.exe : warning HEAT5150 : Could not harvest data from a file that was expected to be a SelfReg DLL: (...) Exception has been thrown by the target of an invocation.` – Damian Vogel Feb 21 '11 at 15:15
  • 1
    Some things I found on the WiX mailing list : 1) It may not work with 64 bit DLLs. 2) Try running heat as Administrator 3) Try running RegSpy as mentioned on this page http://www.installsite.org/pages/en/msi/tips.htm, which will create a .reg file for heat to convert to .wxs. 4) Make sure there are no missing dependencies – AntonyW Feb 22 '11 at 16:33
  • Also, make sure you are using the latest build : 3.5.2519.0. – AntonyW Feb 22 '11 at 16:44