I have a 32-bit VB6 app that was developed on a Windows XP machine which I still have here in the office. The machine is dedicated to this application for on-going support only. All of the licensed ActiveX components are "tied" to this machine.
I have a 2nd computer: a Windows 7 64-bit Pro machine dedicated solely to C# and .NET development.
I recently purchased (at a hefty price of course) InstallShield Pro 2012 which is "tied" to my 64-bit box.
I have copied over all of the 32-bit app components etc. to my 64-bit machine in hopes of FINALLY being able to create a nice and seemless installer for this app.
I have included all of the required ActiveX components into one single directory to make it easier to include in my project. The first time I built the project within InstallShield, it hung at "Extracting COM data from 34 components...". I thought the problem might be with the libraries not being registered on my 64-bit machine so I manually registered each one of them using \Windows\SysWOW64\regsvr32.exe -- this was successful.
At this point, IS 2012 still hangs at "Extracting COM data". I use the Task Manager to bring up the Processes, etc. and the CPU flatlines -- ZERO activity.
I can't install 2012 on my 32-bit box because my license for IS 2012 is tied to my 32-bit box.
This problem was posted 2, maybe 3 times in the forum and the proposed solution of adding a key to the registry did nothing.
Can anyone think of a way to resolve this issue? Is there a major bug in IS 2012 for COM support that hasn't been identified and/or corrected?
1. I went into the Components group. 2. I located one of the many COM components (files). 3. I right-mouse-clicked on the file to Extract COM Data manually and that's when my system crashed.
When I rely on the Build process in IS to extract the COM, my system just hangs and I need to End Process or reboot.
There shouldn't usually be any difference between at-build and on-demand extraction of COM data, at least with regards to crashing. It might be good to isolate whether it is the new COM extraction method which causes this to happen, or the environment within which the COM extraction runs. If you can share the file that you are trying to extract, as well as any of its runtime dependencies, we can attempt to verify and debug things on our end. In the meantime, this may be the registry key you were referring to, but changing its value should prevent InstallShield from using a method which can crash the machine:
HKEY_LOCAL_MACHINE\SOFTWARE\InstallShield\RegSpy (32-bit host) HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\InstallShield\RegSpy (64-bit host) Set the DWORD value name UseAPIRegistryHooks to 1.
I had mistakenly used a string instead of a DWORD value.
After correcting my Registry entry, I was just now finally able to build my installer -- and with only a few warnings. This in itself is an accomplishment.
I will now see how things faired and I will post back with my findings.
