<p>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.</p>

<p>In this post <a href="http://blog.deploymentengineering.com/2008/09/howto-use-regsvr32exe-with-wix.html" rel="nofollow noreferrer">Deployment Engineering Archive: HOWTO: Use Regsvr32.exe with WIX</a>, 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 <code>regsvr32</code> as it registers to the system rather than the user, but I also recall that <code>OleSelfRegister</code> can have issues from a microsoft support bulletin (sorry, can't find the link) - and I believe they recommended using <code>regsvr32</code>.</p>

<p>Any advice?</p>

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.