Critical IS12 flaw with COM Extract at Build
I've managed to minimally reproduce a very serious bug in IS12 SP2 by creating a setup package which is set to install a specific simple COM object.
This COM object is, from everything I can tell, inocuous. It's only a few hundred lines of standard C++ and nothing about its uuids or self-registration is strange.
Here's the problem:
When the component's key file is set to this DLL and the component's COM Extract at Build option is enabled, a seemingly random and critical registry key gets inserted into the resulting MSI file's Registry table.
The key is this:
* (Create if nonexistent; delete on uninstall)
If you install this project (which copies only a single DLL - the destination folder is irrelevant) - when you uninstall it, your system will be completely hosed. Your TCP/IP stack will be corrupted because InstallShield is deleting one of its registry keys. Attempting to run ipconfig on a machine after this package has been installed causes ipconfig to fail with the missing registry key message ("the system cannot find the file specified). Rebooting will render the machine's network stack inoperable. The only way to fix your machine is to restore this registry key from another working machine of the same OS, revert to a system restore point, or repair the system using a Windows installation media.
This is unacceptable. Why would this key be inserted into the registry table? There is absolutely nothing in the source code of this DLL even remotely related to TCP/IP.
This issue can easily be worked around by simply disabling COM Extract at Build and manually extracting the com information by using the advanced node underneath the component. When using this method, all of the standard COM keys are added to the package's registry table as they should but the TCP/IP key is not there. The TCP key is only added to the registry table if COM Extract at Build is used.
This took me several weeks to figure out. I hosed my development machine more than once because of this mysterious bug. I only discovered it was a problem with InstallShield when QA started seeing the same problem when testing the setup.
Like I said, I can minimally reproduce this issue easily with this one DLL. I haven't seen any other DLLs that cause this problem. I can attach it for testing if you would like.
I had just the similar problem.
The only solution I've found was to use Filters.xml to exclude undesired registry keys from COM extraction.
Hope this can help you.
Filters.xml is the suggested solution for this and these cases are the reason it was added.