AS 6 VP1 inserting rogue Multi_SZ

[mupdike]

Hi all, I have a capture (two part snapshot) where I have manually added the following registry key since it was missed:
HKCR\Cortona.Client\shell\open\command\(default)
This is to launch a 3-D viewer plugin for IE via file extension. The problem is that somewhere between pressing the compile button into the setup (single file setup.exe with msi and compressed cab streamed) and the installation; the following value is being added:
HKCR\Cortona.Client\shell\open\command\command
with a value of:
4F^~&&8DZ9d6XJMl.hlEpdSaberNewFeature>v0.gAjCDw9$ZDfN{-t~L -nohome

Now some of the odd things about this are:
1) EpdSaberNewFeature is the name of the master feature in the project.
2) -nohome is one of the switches to the actual launch command in the (default) value in the registry key that is supposed to exist.
3) the plugin will not work as long as this value exists
4) no information in the msi table exists anywhere. I have manually searched the entire project both in the UI and the table itself.

Please help! and I will answer any questions if I have no provided enough details,
Thanks for any and all assitance!!!
Mike

[Ajay_Ladsaria]

I am not sure why that new registry entry is being added, but there are two possibilities of workarounds:

1. Instead of manually adding that registry key, go to the File Association view in the Advanced Settings of a component that contains the EXE to launch as a keyfile. Here create the file extension (this is the MSI supported method for file associations).

2. Instead of adding the key in the ISM and then building, try adding it directly to the MSI.

It is possible that this registry key is being created by MSI to facillitate advertisement of the extension.

-Ajay

[mupdike]

Thank you for the response however that fix is not possible. The exe that the file is associated with is IEXPLORE.EXE which is installed as part of the corporate image and cannot be included in the installation. This is why the file association was done through the registry instead of the normal method.

For #2 I have already checked the raw MSI in ORCA for any odd information and the tables were clear, which to me made the situation even more confusing.

I have been able to put in a viable work around with the importing of a deletion .reg file that will remove the rogue entry so the plugin now works. I would still like to know why this is happening of course since this program is updated appoximately twice a year and this was the first of the two updates for the year.

Again, thank you for the response!
Mike

[David_Thornley]

This registry entry is most likely created by the windows installer engine for use with its Install On Demand and Self repair features. If you manually delete this entry I can't predict whether or not these functions would fail gracefully or not. If you do not want these Windows Installer features you may instead want to use the registry view to manually build up your verbs instead of using the native implementation. If you do want these MSI features then you need to leave these keys alone.

[mupdike]

David,
Thank you for the information! Unfortunately I cannot leave that key alone since it causes the entire program to stop working. The plugin will not launch with any additional registry values in the command key, at least not with any that contain the same name as the key itself. This multi_sz is stopping the plugin from launching iexplore.exe which basically makes the whole program non-functional. The repair process does not fail after deleting this string as I have used repair to bring it back in testing my removal process of the value itself. As for the Install on Demand feature...that is not used at the site that I am working at.