When the product performs an upgrade, everythig seems to work correctly except the file-association registry setting [HKEY_CLASSES_ROOT\\shell\open\command]
The default value is created sucessfully (or at least unchanged by the upgrade)
but a new value named: "command" is created containing random hex data.
The result is that when the user double-clicks on a file, an installer process is started to install a "missing" component!
The creation of these registry entries would be expected if you are using the Extension/Verb tables to create your file extension registration. Windows Installer generates encoded registry values (sometimes referred to as "Darwin Descriptors") that are used to implement advertisement and self-resiliency (auto repair) functionality for MSI installations.
If you do not want these registry entries to be generated by Windows Installer, use the Registry table to install your file extension information.
Thanks, that explains the behaviour I'm seeing, but not how to resolve it (having followed your link I'd rather fix the problem, than go around it)
Is there a way to decode the "Darwin Descriptor" to determine which component and features its' referring to, since there may be a problem in the upgrade?
I know the application itself is being upgraded correctly, because deleting the key causes the file association to work as expected...
There's no known way that I am aware of to decode the descriptors created by Windows Installer.
The correct method of resolving this behavior without changing how file extensions are created by your installation would be to determine the cause of the auto repair. To do so, open the Event Viewer (in Control Panel->Administrative Tools) on the machine(s) encountering this behavior and go to the Application log. In the Application log, look for two MsiInstaller warning entries. One of these entries contains information on what feature/component triggered the repair (in this case it would likely be the component containing the file extension). The second entry contains information on what component Windows Installer believes needed to be repaired and the resource that it determined it missing. You can look for the component code provided in the event log entry in your built MSI package to determine what resources this component installs (note that it is always the key file/key path of a component missing from a machine that causes Windows Installer to attempt to repair the component).
With the information from the auto repair event log entries, you may be able to change your upgrade package to resolve this behavior.
