Unable to register COM dll

[anilkumar_mca]

Hi,
I am migrating a perfectly working msi project from IS12 to IS2009.
Issue:
I am unable to register a COM dll in 64Bit.
Error:
I am getting
'error 1904. Module C:\Program Files\MyCompany\....\Mydll.dll failed to register HRESULT -2147220473. Contact your support personel.'
Information:
I am able to register that dll using regsvr32 from command prompt.
Any Idea?

[bobmcm]

I am running into a similar problem, but in my case it happens on Window Server 2008 both 32 and 64 bit. If I run the installation twice, doing a repair on the second try, it registers correctly, and if I manually register the file it also works correctly. I have tried reordering the files, re-creating the installation, but nothing that I have tried makes it work correctly on the first install.

[datamine]

Hi folks

Self-registering dlls at install time has gone against "InstallShield Best Practices" for a while now, I presume for the reasons you're encountering. Certainly, the 64-bit issue will be a problem, as I'm assuming this is a 32-bit dll which will be installed to Program Files (x86) on a 64-bit system.

This is the reason why it is recommended that you set COM components to "Extract COM at Build", which will set up the correct COM registry entries at build time. This also has the added benefit of effectively unregistering the components automatically on uninstall.

Hope this helps

Ian Johnson.

[LaserVision]

Hi,

I have encountered the same problem and the only thing we found out was that an environment path was missing - the path to the directory were the executables are. If you set it before installing and then don't get an error message then we would have the same problem: I figured out how to set the environment path with the setup but still it does not work although it is written when the message box pops up.

"Extract COM at Build" does not work with my dll - building the project I get "ISDEV : warning -4354" (to see more...) which leads to an unregistered dll which therefore forces me to do self registration with the dll.

So, the only solution I would have is to figure out why our and probably your dll(s) is using the environment path and how we could get rid of it. Does anyone have a hint?

Writing that self registering is against "InstallShield Best Practices" sound exactly like best practice when you have no solution to a well known problem...

Ciao
Antonio

[anilkumar_mca]

Hi,

Please check in the below link..... I raised the above issue in one of my another post...... one of the Acresso people replied to my issue as:


What table are you using to self register this DLL (MSI SelfReg or InstallShield ISSelfReg)? If you're using the InstallShield table, the DLL will not successfully register (the ISSelfReg support cannot load 64-bit DLLs). In this case, the record for the DLL should be removed from ISSelfReg and added to the SelfReg table.

Another thing to note is if there are missing dependencies required to successfully register the DLL, it will fail to register. The most common cause of this recently is a dependency on Visual C++ 2005 or 2008 runtime DLLs, which are Win32 side-by-side assemblies. Due to how Windows Installer installs assemblies, self registration with either table or regsrv32 (through a custom action) will fail before InstallFinalize (assemblies are not committed until after InstallFinalize, and both self registration tables run self registration before InstallFinalize).

For more details:
http://community.acresso.com/showthread.php?t=186137&page=4&highlight=wrong+install

[bobmcm]

anilkumar_mca wrote:
Another thing to note is if there are missing dependencies required to successfully register the DLL, it will fail to register. The most common cause of this recently is a dependency on Visual C++ 2005 or 2008 runtime DLLs, which are Win32 side-by-side assemblies. Due to how Windows Installer installs assemblies, self registration with either table or regsrv32 (through a custom action) will fail before InstallFinalize (assemblies are not committed until after InstallFinalize, and both self registration tables run self registration before InstallFinalize).

This makes sense based on my testing, but I would assume that this would be OS and bit depth independant as the Windows Installer is being used in all cases. Yet with my installation, the same installation package works installs and registers correctly under Windows 2003 Server, but fails to register under Windows Server 2008.

Luckily, I was able to get the appropriate registration information, and manually input this into the installation. Extract COM data failed in my case also. This resolved my issue, but I forsee that this is going to come back again in the future. Also, one must remember, not all self registering DLLs are COM objects, and the Extract COM data will not resolve the issue.

Robert McMahan
Futuresoft, Inc.