Registering a COM server with WiX

Question

I have been trying to determine a best case solution for registering a COM server using WiX to create a Windows Installer package and am struggling.

In this post Deployment Engineering Archive: HOWTO: Use Regsvr32.exe with WIX, there is an open request for the "Setup police" to crack down on using regsvr32 through an exe custom action. I know the evils of using regsvr32 as it registers to the system rather than the user, but I also recall that OleSelfRegister can have issues from a microsoft support bulletin (sorry, can't find the link) - and I believe they recommended using regsvr32.

Any advice?

Answer 1

Read "Do not use the SelfReg and TypeLib tables" at:

https://msdn.microsoft.com/en-us/library/bb204770#no_selfreg

For WiX, take a look at the Component element in the schema reference at:

http://wixtoolset.org/documentation/manual/v3/xsd/wix/component.html

Take notice of certain child elements such as AppId, Class, ProgId, Registry and so on. The proper technique is to use COM extraction to reflect the registration information and emit it declaratively into your installer so MSI can take care of it for you without going out of process to some code (like DllRegisterServer()) that could fail and also not provides MSI insight into the footprint of the component from a repair and advertisement perspective.

Answer 2

There is a tool "Tallow" included with Wix. You can use it to generate correct registry entries automatically. Then you just configure your wix installation to write those entries. Selfreg should not be used.

Answer 3

As @Trampster pointed out, heat.exe does not do a good job of harvesting registry entries from COM servers. I tried but the results were incomplete.

Instead, following the advice at Monitor Registry Accesses (InstallSite Tools: Monitoring), I used InstallShield RegSpyUI. This supposedly ships with versions of Installshield v7 and beyond, including the evaluation version. This information may be out of date; I can confirm that it is not supplied with the pretty-much useless Installshield LE that comes with VS2013.

Luckily I did have a copy of InstallShield 2010 and this did come with RegSpyUI.

Anyway, RegSpyUI was a breeze to use: point it at the COM .exe, extract the registry info to a .reg file. Then use heat to harvest this into a .wxs file you can add to your Wix project

heat reg <some.reg> -gg -o <some.wxs>

Then it's just a matter of modifying any hard coded paths that point to the COM .exe's location so they reflect the intended installation folder.

e.g. if the .wxs file created by RegSpyUI+heat has something like this

<Fragment>
    <DirectoryRef Id="TARGETDIR">
        <Component Id="blah" Guid="{xxxxxxxxxxxxxxxxxxxxxxxxx}" KeyPath="yes">
            <RegistryKey Key="TypeLib\{xxxxxxxxxxxxxxxxxxxxxx}\4.1\0\win32" Root="HKCR">
                <RegistryValue Value="C:\Users\you\projects\MyProject\dependencies\installation\COMFOO.exe" Type="string" />
            </RegistryKey>
        </Component>
    </DirectoryRef>
</Fragment>

and you are installing in your main wix file to

<Directory Id="TARGETDIR" Name="SourceDir">
        <Directory Id="ProgramFilesFolder" Name="PFiles">
            <Directory Id="COMPANY" Name="My Company">
                <!--This is the actual installation folder-->
                <Directory Name="MyProduct" Id="MYPRODUCT">

then simply edit the RegistryValue@value path to ..."[MYPRODUCT]\COMFOO.exe"

Answer 4

There is just one drawback to this: WiX Com registration with heat.exe does not work for .exe COM servers. InstallShield and its tools seem to support it, but RegSpyUI is just a UI tool, not one which I can run on my build machine.

Answer 5

Try this:

1. Create a new .NET project
2. Add a project Reference to the candidate COM dll or OOP exe whose wxs you want to gather
3. Search for the file Interop.candidate.dll (in the obj\debug folder)
4. Run the WiX Heat tool on the interop dll you just found.