CODEWITHSUNDEEP
wixregsvr32
Dai
Dai

Reputation: 155543

Running regsvr32 as part of a WIX installer

I have authored a COM component that is distributed through a WIX-generated MSI.

The COM component has rather complicated and non-static registration logic which means that embedding the registration information directly in the Windows Installer WXS file is not a feasible option - registration must be done using regsvr32 - and it's a 32-bit COM component, so it must use the 32-bit version of regsvr32.exe - that is %SystemRoot%\SysWow64\regsvr32.exe on 64-bit Windows or %SystemRoot%\System32\regsvr32.exe on x86 Windows.

I noticed two problems with WIX with this WXS XML:

<InstallExecuteSequence>
    <Custom Action="COMRegister"   After="InstallFinalize">NOT Installed</Custom>
    <Custom Action="COMUnregister" After="InstallInitialize">Installed</Custom>
</InstallExecuteSequence>

<CustomAction Id="COMRegister"   Directory="APPLICATIONROOTDIRECTORY" ExeCommand='regsvr32.exe /s "[APPLICATIONROOTDIRECTORY]Component.dll"' />
<CustomAction Id="COMUnregister" Directory="APPLICATIONROOTDIRECTORY" ExeCommand='regsvr32.exe /s /u "[APPLICATIONROOTDIRECTORY]Component.dll"' />
  1. The wrong regsvr32.exe was being invoked. I noticed that the x64 version of resgvr32.exe was being run on 64-bit systems instead of the 32-bit version.
  2. regsvr32.exe was being run without elevated permissions, so COM registration failed with E_ACCESSDENIED.

For 1. it works if I hardcoded the path to the regsvr32.exe executable using [WindowsFolder]\SysWOW64\regsvr32.exe, but this wouldn't work on a real 32-bit machine where SysWow64 doesn't exist.

For 2. I read online that changing After="InstallFinalize" toAfter="RemoveExistingProducts"would cause it to run with elevated permissions, however instead this just gives me errors aboutRemoveExistingProducts` being an unresolved symbol name.

How can I resolve these two issues?

Update

(After struggling with this problem for the past 2 hours, I'm convinced the authors of WIX are close relations of H.P. Lovecraft)

I've worked-around the first issue by writing my own intermediate-step program which is a 32-bit executable, so it will always run under a WOW context, so it will reliably invoke the 32-bit regsvr32.exe program.

I found out the issue with the second issue was these things: For a CustomAction to run with elevated permissions (well, in the same security context as the main installer job) these conditions must be true:

  1. <Custom/>" must haveBefore="InstallFinalize", and **not**After=""any other values forBefore=""` won't work reliably as WIX or Windows Installer might rearrange the actions (wut).
  2. <CustomAction /> have have these attributes explicitly set:
    • Execute="deferred"
    • Impersonate="off"

Even-so, I would like to not have to use my helper program to correctly resolve the 32-bit regsvr32.exe. What options are there?

Upvotes: 5

Views: 5914

Answers (2)

Stein &#197;smul
Stein &#197;smul

Reputation: 42206

This sounds like something that will cause you lots of problems later. Though it sounds like you are determined to use this self-registration, please read this whole post: Self-Registration considered harmful.

Software that is doing "odd things" during self-registration are really frowned upon when found in application packaging in larger companies. Sometimes it is reason enough to throw out the entire software.

If you have stuff you need done with admin rights before your application can run, you should do it as part of the installer, but not via self-registration (see a plethora of reasons in the linked post above). It is better almost any other way, including having your main application.exe run with a command line from a custom action to trigger the custom registration steps, and then provide a good log of what has actually been done. And you should revert to normal COM registration and extraction for the COM servers.

It would be interesting to hear what is unique about your COM servers? Is it the usual licensing issue?

Upvotes: 3

Neil
Neil

Reputation: 2727

I wouldn't advise using self registration at all it is not the really the right way to do it with Windows Installer, if you really must set File/@SelfRegCost to 1.

A much better way is to extract the registry values and write them with WiX - you can also use heat to generate the values.

Upvotes: 6

Related Questions