11 replies to this topic

[AntonS]

Hi,

I try to execute a Major Upgrade.

ProductCode differ for Upgrade product and an Old product.

Upgrade table

UpgradeCode {18FC1E32-F0E7-455B-A1EC-10E487C37E67}
Attrubutes 5
ActionProperty UPGRADE_ACTION

I create a new property UPGRADE_ACTION

Standard Actions placed in next order InstallExecuteSequence table

CostFinalize
FindRelatedProducts
MigrateFeatureStates
…
InstallFinalize
ISSelfRegisterFinalize
RemoveExistingProducts

MajorUpgrade finished completely, but if I try to remove Upgrade product, files from an Old product remain in the system.

What else?

I need to completely remove all files after uninstall.

Any suggestion will be helpful.

Thank you.

[Stefan Krueger]

Does the old product get properly removed during the upgrade? Try to change attributes to 1 to make sure you notice if it doesn't.

If you only install the old version (not upgrade), and uninstall it, do these files get removed? (Otherwise it's a problem in your old version)

[AntonS]

Thank you!

Seems old product uninstall stopped to remove files.

But RemoveFiles standard action exist in uninstallation log:

[Stefan Krueger]

These components may be marked as permanent, or they have a reference count > 0

[AntonS]

But this components can not have refcounts > 0 if there no more product, which can they use, I suppose?

Components is not permanent, cause of attribute field in Components table:
msidbComponentAttributesSharedDllRefCount (8)

When files removed, log file content GenerateScript message:

[Stefan Krueger]

Oh, you say you have no RemoveFiles action in your log? That explains why the files are not removed
You need to find out why this action doesn't execute. Maybe there's a conditon on it?

[AntonS]

No, I mention that log files differ for my installation and other installation, for which files removed successfully.

My installation log did not contain message: “GenerateScript: Removing files”

[Stefan Krueger]

Sorry, I don't see anything obvious. A verbose log file might have additional useful information. Maybe contact Microsoft support.

[Glytzhkof]

It could be that you have changed the component GUIDS for some of these files and windows sees them as shared? Is the "Shared" property of the components containing the problem files set to "Yes"? I believe this setting will force windows installer to use old style reference counting (this is for compatibility with older installers).

When doing a major upgrade I have seen this "files remain" problem before, and as I recall it was because I either changed a component GUID for an existing file, or removed a file and then added it again with a new GUID (essentially the same operation).

[Glytzhkof]

Maybe try to disable the Shared property in your new installer and see if that makes a difference for the major upgrade.

[AntonS]

Thank you very much!

It's resolved.

According to your assumption, in previous installation components defined as Shared.
Regardless to change component type in next installation packages, reference counts remain in target system.
After that I remove it from registry: HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDlls

Certainly, I did not change component GUID not changed.

Thank you again, sorry for inconvenience.

[Glytzhkof]

Installshield sets that property to Yes by default, I am not sure if this is the best choice. I think it should be set to yes only for files installed to the system folder.