9 replies to this topic

[realityworks]

I've got a major upgrade running here and it generally works correctly except that I've got a blank user data file that is defined as a separate component. It is set up to never overwrite and is set up as a key file, set permanent and shared (the original install did not have these set). I've got the major upgrade settings set up to install then remove files.

What's happening is that the existing file is either being deleted or overwritten in the end -- I end up with the new data file instead of keeping the existing file.

The log sez that it won't install the file 'cause it see it is already there (never overwrite) and promptly uninstalls it as part of the uninstall cleanup.

Got any ideas of what majical incantation is required here?

[Glytzhkof]

Have you matched the component GUID for the file from the previous version? In other words is the file still installed with the same GUID used? If not, you should match up the GUID, then the major upgrade should not remove the file provided you run the RemoveExistingProducts action late in the InstallExecute sequence. If you run it early the old version is completely uninstalled before the reinstall. Remember that you can't change how the uninstall of the existing version works without patching it using a minor upgrade.

[realityworks]

I'm pretty sure that the GUIDs are the same between the versions. In looking at the last one, it looks like the shared bits were set on, tho. Attached is the log created if that helps some...

Attached Files

•  inst2.zip   54.02KB   73 downloads

[Glytzhkof]

Did you perhaps move the file to a different component in the new setup?

[realityworks]

no, same component (Allotherfiles3)

GUID is {CBF1F722-4305-486A-8C83-C5A2C08383A2}

[Glytzhkof]

This could explain things. Is the file in question the key file of this component? Also, are you using dynamic component linking?

[realityworks]

Ahhhhh, yes, this is the key file for the component, but the last install didn't have it marked as such which probably screws up the install then because they are being treated differently? Any way around it?

I don't know the term dynamic component linking... Different file content than the first one, I just don't want to put it in place if the first one is there...

Joy, joy, joy....

[Glytzhkof]

This will be difficult to make reliable by MSI alone. I think I would bit the bullet in this case and use a custom action to back up the file and then put it back after the install finishes. A custom action like this HAS TO be well conditioned so it doesn't overwrite the wrong type of file, I would try to insert the backup custom action before InstallInitialize in the immediate sequence and then put the copy back action right before InstallFinalize in the deferred sequence.

[Glytzhkof]

A component is either installed completely or not at all. The key file for a component is what is used to determine if the component is to be installed or not. This is the reason why executables are to be in a component by themselves - to ensure that they are always the key file and hence always updated. If you don't specify a key file for a component it will generally specify it's parent folder as the key file. This is not very good since this will not trigger reinstall unless the whole folder is removed first.

[Glytzhkof]

Also note that keypaths pointing to directories can also cause cyclic MSI repairs since MSI will remove empty directories, then reinstall them again since they are key paths and then remove them again since they are empty. The conclusion: don't use directory key paths.