WiX COM registration error, but export reg keys, delete and re-import

Question

I created MSI using WiX. I am trying to register .NET components for COM interoperability in x64 Windows Vista. However, after starting the MSI installation and then starting the site that uses these components, I see this error message:

Component execution failed for component [0xC] hr: 0x0 CLSID: {3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774} The component could not be created. This may be a component registration problem.

It seems that this is not caused by the usual problems, and after many games I found that I can solve this problem by following these steps:

• Export the registry entry CLSID \ {3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}.
• Delete the key and all subsections of CLSID \ {3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}
• Reimport the exported .reg from step 1.

After completing these three steps, the component will be correctly resolved, and the web application will work fine.

Update. I just exported the entire HKCR registry key after starting my installer, and then following the 3 steps above. Running diff on two files doesn't reveal any differences!

So my question is: what do I need to do for my WiX installer to work? I suppose I'm doing something wrong, but what?

FYI. I use the following WiX XML to create registry keys (I already tried using a WiX class element, but that didn't work either). Note: var.CLSID is a variable with HKCR \ CLSID (not Wow6432Node).

<RegistryValue Root="HKCR" Key="$(var.CLSID)\{3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}" Value="Awesome.Component" Type="string" Action="write" /> <RegistryValue Root="HKCR" Key="$(var.CLSID)\{3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}\InprocServer32" Value="mscoree.dll" Type="string" Action="write" /> <RegistryValue Root="HKCR" Key="$(var.CLSID)\{3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}\InprocServer32" Name="ThreadingModel" Value="Both" Type="string" Action="write" /> <RegistryValue Root="HKCR" Key="$(var.CLSID)\{3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}\ProgId" Value="Awesome.Component" Type="string" Action="write" /> <RegistryValue Root="HKCR" Key="$(var.CLSID)\{3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}\Implemented Categories\{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}" Value="" Type="string" Action="write" /> <RegistryValue Root="HKCR" Key="$(var.CLSID)\{3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}\InprocServer32\0.9.2.0" Name="Class" Value="Awesome.Component" Type="string" Action="write" /> <RegistryValue Root="HKCR" Key="$(var.CLSID)\{3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}\InprocServer32\0.9.2.0" Name="Assembly" Value="AwesomeAssembly, Version=0.9.2.0, Culture=neutral, PublicKeyToken=8a030859d27c8274" Type="string" Action="write" /> <RegistryValue Root="HKCR" Key="$(var.CLSID)\{3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}\InprocServer32\0.9.2.0" Name="RuntimeVersion" Value="v2.0.50727" Type="string" Action="write" /> <RegistryValue Root="HKCR" Key="$(var.CLSID)\{3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}\InprocServer32\0.9.2.0" Name="CodeBase" Value="file:///[#fil7B6E8E93E37519B6844149C87BAD9C0B]" Type="string" Action="write" /> <RegistryValue Root="HKCR" Key="$(var.CLSID)\{3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}\InprocServer32" Name="Class" Value="Awesome.Component" Type="string" Action="write" /> <RegistryValue Root="HKCR" Key="$(var.CLSID)\{3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}\InprocServer32" Name="Assembly" Value="AwesomeAssembly, Version=0.9.2.0, Culture=neutral, PublicKeyToken=8a030859d27c8274" Type="string" Action="write" /> <RegistryValue Root="HKCR" Key="$(var.CLSID)\{3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}\InprocServer32" Name="RuntimeVersion" Value="v2.0.50727" Type="string" Action="write" /> <RegistryValue Root="HKCR" Key="$(var.CLSID)\{3C1CEEC0-3B20-46F8-8D4E-5F16E93D8774}\InprocServer32" Name="CodeBase" Value="file:///[#fil7B6E8E93E37519B6844149C87BAD9C0B]" Type="string" Action="write" /> 

Answer 1

Answer (for me) Registry Permissions!

After a good night’s sleep, I realized that if the export of entries to the registry does not differ, the answer should lie in the difference in the registry, which is not exported. Of course, one of the possibilities (perhaps the only one?) Is access rights to the registry.

Armed with the best conditions for Google, I found the Heat and COM registry Permissions stream. This section explains that if you do not have the WiX ALLUSERS property with a value of 1 (ie <Property Id="ALLUSERS" Value="1" /> ), then by default your installer will start and install registry keys in the bush for each user. Therefore, why my web application could not see them (since it works as another user) and could not create them.

The moral of my story is: you cannot expect Heat.exe to do all the work. You can't just stumble with WiX and MSI.

I would like the WiX installer project to be in some specific checklist ...