we are using IS2010 on a 64-bit Windows 7 operating system and now we have some trouble using COM extraction for some of our COM binaries.
Problem: COM extraction does not extract all COM information (some Registry table entries are missing, maybe more). The same COM extraction works fine using IS2009 on 32-bit XP.
If the missing information is related to typelib or interface registry keys, is UAC disabled on the machine(s) you are using COM extraction on (or is InstallShield running in a limited user account)? If so, please try creating an environment variable named "OAPERUSERTLIBREG" and set its value to 1 (restart or reopen InstallShield after creating the variable).
That should be interface registry keys afaik (CLSID\{GUID}...'FriendlyName', 'Merit', 'FilterData', 'ThreadingModel' and so on). UAC is enabled (default Windows 7 setting) but I am launching the InstallShield IDE across Total Commander and Total Commander runs elevated on my system. Could that be the problem?
Note that if you are launching InstallShield from another process that is running on the machine, that process may also have to be restarted to see the environment variable change if it does not listen for or receive the WM_SETTINGCHANGE message.
Also, regarding interface keys, these are GUID keys created under HKEY_CLASSES_ROOT\Interface. Type libraries are written to HKEY_CLASSES_ROOT\TypeLib. Keys written to these locations may not be captured correctly on Vista SP1 or newer systems in certain circumstances. Creating the OAPERUSERTLIBREG environment variable is a work around to a change in how the RegisterTypeLib API works on Vista SP1 or newer.
If you are seeing a problem with other keys (not HKCR\Interface or HKCR\TypeLib keys) missing, then the environment variable will not change the behavior you are seeing. If this is the case, we would need additional information to be able to isolate the cause of the behavior you are seeing.
If you are seeing a problem with other keys (not HKCR\Interface or HKCR\TypeLib keys) missing, then the environment variable will not change the behavior you are seeing. If this is the case, we would need additional information to be able to isolate the cause of the behavior you are seeing.
I got it wrong the problem occurs with those other keys and not HKCR\Interface keys. How do we proceed? I would like to email you one of our COM filters and my sample projects (IS2009 and IS2010). Or should I log an support incident?
If you would like, you can send the COM servers that do not get all information extracted as expected to jstechnij@flexerasoftware.com. It is possible that the behavior you are seeing is related to an existing known issue with the current COM extraction implementation (if the COM server registration depends on any existing registry information, this information will be unavailable during COM extraction) or if this is a different issue. As a whole, COM extraction was not changed much from IS 2009 to 2010, so the issue here could be related to the underlying operating system used to perform COM extraction on.
