I've been thinking about it more, and I realize that I actually experienced that problem using IS12! What this means is that while the hotfix is available for IS2008, IS12 users are actually at risk also. The KB article says that it applies to IS2008 but it should also say that it applies to other versions since the work around notes state:
Workaround
For users who are not using InstallShield 2008, please use the following steps to work around this behavior:
Disable the 'COM Extract at Build' property for the component with the '*' character in the 'Name' column of the registry table
Locate the 'Advanced Settings' -> 'COM Registration' view of the component
Right click on 'COM Registration' in the middle pane, and select 'Extract COM Data for Key File'
In the Direct Editor, locate the offending entry with the '*' character in the 'Name' column of the registry table, and delete it.
A hotfix for IS12 would be good, but to be honest, I don't reccomend using COM Extract at build unless you always plan on doing Major Upgrades and you know your COM components don't have binary compatibility.
4 comments:
I called Macrovision's tech support to get some other clarification on this problem, and the person I spoke to said it actually applied to versions 11.5 or later (!!)
Sairen, that would not surprise me as they made several changes in 11.5 to COM extraction.
Christopher thanks for mentioning this. I certainly stopped and started to browse our MSI package for these entries.
We just ran into this when our upgrade killed Outlook 2007. There are spurious * entries in the COM extracted registry entries - like for instance "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" and a few other choice locations. When the uninstaller is invoked, these keys are cleared. Ouch!
Always good to run validation to sort out problems such as this. Not sure if ICE would have caught this, but a custom registry checker ICE can easily be created to do so.
Post a Comment