We are getting an error when trying to install a 64-bit OCX. with HRESULT -2147220473.
However, when the installation fails and we manually try to register it via REGSVR32.EXE it works, so all its dependencies seem to be installed properly. Very bizarre.
Per some other threads I tried turning off Self Registering the OCX and setting the COM Extract at Build to Yes, but that didn't work either. It didn't give an error but it didn't register the OCX and when I ran REGSVR32 on it, it failed.
So I'm wondering if it's a timing issue or order issue.
1. Could InstallShield be trying to register the OCX before other files in the setup are properly installed?
2. Do I need to or is there a way to make sure this is the last object to be registered?
So I'm wondering if it's a timing issue or order issue.
1. Could InstallShield be trying to register the OCX before other files in the setup are properly installed?
2. Do I need to or is there a way to make sure this is the last object to be registered?
Thanks.
1. It could be! It is possible it requires another file to be registered first. Unfortunately, you'll have to manually figure out this dependent ordering.
2. There is a way. If you set it to self-register (and use the InstallShield self-registration option in the settings), you can go to the ISSelfReg table in Direct Editor and populate the 'Order' column
A question you didn't quite ask was about how COM Extraction helps with ordering. So here goes:
If you ensure everything is correctly registered on the build machine, then
Com extraction reduces the registration process to Windows Installer operations that don't require executable code running inside the *.ocx (and thus fail because of dependent ordering)
It's for this reason that COM Extraction makes the setup more reliable. But... You still have to figure out the correct order to register them in to prepare the build machine for the project build. Otherwise, the build will fail with an error attempting COM Extraction.
