MSI Desparation. MSI WILL NOT REGISTER DLL

My MSI installer will NOT register DLL on XP. On Vista it won't register unless I am an administrator. and on Win7 it will RANDOMLY register the DLL or not.

After the MSI won't register the DLL, Users are forced to go to the install folder, type "regsvr32 mydllname.dll" - and then everything works (which proves the DLL is healthy and fine).

The "register" property for this file is "selfReg" in the MSI project. "COM" doesn't work too.

I am beginning to think either I am hallucinating or MSI simply cannot register DLLs.... very, very VERY frustrated. already a WEEK into trying to resolve this and NADA开发者_如何学Python. I really hate MS at this point.

Please, help.

What most probably is happening, is that your registration code is writing to the wrong registry root. For example, HKCR is a merged view of HKLM\Classes and HKCU\Classes, and the registration to HKCR in some cases will end up in the HKCU\Classes, and sometimes in HKCU\Classes\VirtualStore depending on which OS and what account the installer was run under.

In addition, if you are depending on the DllRegisterServer to register your COM dll from the MSI, the MSI engine doesn't even know about your registry entries and it's up to the actual DLL code.

What I would suggest is to change your MSI to not use the auto-registration using DllRegisterServer and not do the registration under HKCR. Instead, add your registration as explicit registry entries under HKLM\Classes (unless you have specific reasons to require per-user COM registration, which is a whole different topic).

Yeah, a good one answer by Franci Penov. As an option you may also try adding

regsvr32 yourdll.dll

as a custom action on installexecute sequence after files are deployed and the same one for removal but with /u key to unregister

Registration in HKCR (and related mapped hives) requires admin privilege and always did. This is essentially the same problem as "I could write to the Program Files directory in XP but not in Vista". That's because everyone was an administrator on XP but since UAC nobody is an administrator unless they elevate somehow (run as administrator being a common one, the other being a UAC elevation prompt).

Common reasons for self-registration to fail at install time are:

1. Lack of elevation (such as a per user install that never shows a UAC elevation dialog).

2. Missing dependencies. There may be a Dll that yours depends on, and it's not on the target system. If registration works AFTER the install is complete you may have a dependency on a Win32 or managed code assembly. If you have a dependency on a C++ runtime that goes to WinSxS and you included it as a merge module then it won't be committed until after the install has finished and your registration will fail. The same is true of assemblies going into the GAC but that seems unlikely in your Win32 registration case. If it's random on Windows 7 that's typically because some systems already have (say) the C++ runtimes installed and some don't.

Most tools these days, including Visual Studio and WiX, can do extraction of COM registration at build time. It's static data so there's no reason it can't be in the MSI file. In the WiX case the tool is called Heat. It also means there is no need to call the Dll at install time, avoiding dependency issues. The vsdraCOM setting does this and I've used it successfully, but like every registration it requires dependent Dlls to be available at build time. There's no good way to see if it's worked, but if you get an MSI editor (such as Orca from the Windows SDK) and open the MSI file with it you should see your classes in the Class table, and there'll be something in the Registry table.

It might also help if you had more detail about what "will not register" actually is. Are there missing Interface entries, CLSID entries, error messages at install time, apps that fail to run because they can't instantiate a class?