This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Problem with COM extraction during build
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Aug 25, 2011
12:29 PM
Problem with COM extraction during build
Just converted from 2011 to 2012 and now my application doesn't work.
Turns out that a lot of the COM interfaces aren't registered. The 2012 MSI has 2597 entries in the registry table instead of the 4485 entries I had in 2011 MSI.
Will investigate further but if anyone has a clue or hint please help me.
Turns out that a lot of the COM interfaces aren't registered. The 2012 MSI has 2597 entries in the registry table instead of the 4485 entries I had in 2011 MSI.
Will investigate further but if anyone has a clue or hint please help me.
(2) Replies
‎Aug 25, 2011
04:48 PM
As a general direction to take here, if any of these files do not completely remove their registry data when they are unregistered, the new COM extraction is likely to miss the data. The reason for this is as follows:
- The new COM extraction monitors registry activity for the process registering a file
- In order to ensure spurious registry information does not get captured, only registry create operations are captured
- If a registry key exists that a COM object would normally register, the key is opened by Windows, not created, which results in the COM extraction ignoring the key
- To attempt to cover for this scenario, the COM extraction performs an unregister operation on the file and captures all keys that are deleted; the extraction then registers the file normally, key open operations are checked against the list of deleted keys and captured if they are in the list
- If a key is not removed during unregistration of a file that it would normally create, there is nothing to indicate to the COM extraction that a given key is owned by the file being registered, or if it is a Windows registry key, or if it is owned by a completely unrelated file/vendor
So, one thing to check here for files that seem to be missing COM data after extraction is register the file on a clean machine, then unregister it. If the file leaves behind any registry keys, these won't be picked up during COM extraction (typelib/interface keys seem to be the worst at being cleaned up for some reason).
If, for some reason, the unregistration for these files cannot be changed, you can change the COM extraction to use the method provided by IS 2011 and older versions by adding/changing the following value:
HKLM\Software\InstallShield\RegSpy
UseAPIRegistryHooks (REG_DWORD): 1
Possible values for UseAPIRegistryHooks:
0 - Use old (pre-IS 12) user mode API hooking
1 - Use registry redirection (IS 12+)
2 - Use kernel mode registry filtering (IS 2012+)
- The new COM extraction monitors registry activity for the process registering a file
- In order to ensure spurious registry information does not get captured, only registry create operations are captured
- If a registry key exists that a COM object would normally register, the key is opened by Windows, not created, which results in the COM extraction ignoring the key
- To attempt to cover for this scenario, the COM extraction performs an unregister operation on the file and captures all keys that are deleted; the extraction then registers the file normally, key open operations are checked against the list of deleted keys and captured if they are in the list
- If a key is not removed during unregistration of a file that it would normally create, there is nothing to indicate to the COM extraction that a given key is owned by the file being registered, or if it is a Windows registry key, or if it is owned by a completely unrelated file/vendor
So, one thing to check here for files that seem to be missing COM data after extraction is register the file on a clean machine, then unregister it. If the file leaves behind any registry keys, these won't be picked up during COM extraction (typelib/interface keys seem to be the worst at being cleaned up for some reason).
If, for some reason, the unregistration for these files cannot be changed, you can change the COM extraction to use the method provided by IS 2011 and older versions by adding/changing the following value:
HKLM\Software\InstallShield\RegSpy
UseAPIRegistryHooks (REG_DWORD): 1
Possible values for UseAPIRegistryHooks:
0 - Use old (pre-IS 12) user mode API hooking
1 - Use registry redirection (IS 12+)
2 - Use kernel mode registry filtering (IS 2012+)
‎Aug 26, 2011
01:48 PM
I saw two type problems with COM-extraction after upgrading from IS2011 to 2012:
1) 4354: The build was unable to extract COM information from a file in a component. Ensure that the file is self-registering and verify that the self-registration process does not fail. I verified that all failing components could register with regsvr32.
2) COM-actracting an exe-file launches the application. Maybe IS2012 does not launch the exe-file with /selfreg as argument?
After changing to the old method with UseAPIRegistryHooks=1 I had a successful build.
1) 4354: The build was unable to extract COM information from a file in a component. Ensure that the file is self-registering and verify that the self-registration process does not fail. I verified that all failing components could register with regsvr32.
2) COM-actracting an exe-file launches the application. Maybe IS2012 does not launch the exe-file with /selfreg as argument?
After changing to the old method with UseAPIRegistryHooks=1 I had a successful build.