Question

<CustomAction Id="RegisterEXE"
                Directory="INSTALLDIR"
                  ExeCommand="&quot;[INSTALLDIR]MyApp.exe&quot; /Register"
                  Execute="immediate"
                  Return="ignore"                  
                 />

 <InstallExecuteSequence>
      <Custom Action='RegisterEXE' After='InstallFinalize' />
 </InstallExecuteSequence>

The exe should be registered as ole server. but it does not register.

Was it helpful?

Solution 2

The CustomAction Attibute Impersonate has default value of yes. You need to set it to no to run the executable with Elevated permission (The permission which installer have now). OLE Server registration requires changes in HKCU and HKLM.

Read Wix doc

<CustomAction Id="RegisterEXE"
                  Directory="INSTALLDIR"
                  ExeCommand="&quot;[INSTALLDIR]TKW5.exe&quot; /Register"
                  Execute="deferred"
                  Return="ignore"  
                  Impersonate="no"
                 />

<InstallExecuteSequence>
      <Custom Action='RegisterEXE' After='InstallFiles' />
</InstallExecuteSequence>

OTHER TIPS

Per Windows Installer Best Practices:

Do not use the SelfReg and TypeLib tables.

•Installation package authors are strongly advised against using self registration and the SelfReg table. Instead they should register modules by authoring one or more of the tables in the Registry Tables Group. Many of the benefits of the Windows Installer are lost with self registration because self-registration routines tend to hide critical configuration information. For a list of the reasons for avoiding self registration see SelfReg table.

•Installation package authors are strongly advised against using the TypeLib table. Instead of using the TypeLib table, register type libraries by using Registry table. If an installation using the TypeLib table fails and must be rolled back, the rollback may not restore the computer to the same state that existed prior to the rollback.

The reason is that self registration is an out of process execution that is slower, prone to failure and untrackable by the Windows Installer. This creates problems for resilency, rollback, uninstall and upgrade scenarios. The better approach is to "harvest" the COM metadata from the EXE and author it natively into the MSI. This way MSI simply copies the files and applies the registry entries. In the event of a rollback, MSI knows what it did and simply reverts it. For more information see:

Reasons for Avoiding Self Registration

The way to achieve this in WiX is to run the EXE through Harvest Tool (Heat). This will generate a .WxS fragment that you can then include in your installer.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top