Software Deployment

what about the other apps that installed them & upped the count? If your app on uninstallation reduces the count by one, then technically you have achieved your goal & left the box as when you found it. Why would you want to risk breaking other apps? Your install should only remove what it put down, & maybe by extension any user or app related files/settings created post installation by the app alone.. if you are laying down newer versions of the files i would suggest app isolation using either .local (dll/com redirection) or manifests (win32 assemblies)... do you have sort of conflict management in place? What is your CM tool of choice?

We have no conflict management system in place.

I haven't achieved my goal because when doing the major upgrade it should remove all of the files and reinstall. But because the shareddll count is greater than 1 these files are not being removed and as a result the upgrade is not working correctly because some of the files are upgraded and others aren't causing our software to fail when customers try and use it. The only files this affects are the ones that are installed for our software these files can not be used by any other applications. The reason we have ended up with this problem is because of old installers which didn't work correctly.

The only solution we have at the moment is not good. The customer has to uninstall our application and manually remove the shareddlls then reinstall the application, we don't want to have to do this because most of our customers are not computer people and it wastes their time. An upgrade should upgrade.

I forgot to say that I am using installshield 2008 to create the installer.

Well, if you know for sure that you own these files, then why not utilize the RemoveFile & RemoveRegistry table to whack the problematic remnants & maybe a CA to completely delete any remaining directories. Also, as you "own" the software, if you have properly versioned your files, then windows installer should be installing your newer versions over the old ones... it all comes down to the integrity of your installer package... did you guys cut any shortcuts? Are you one of those vendors we are constantly ranting about in here?

The removefile table I have managed to get working to remove the file but the ref count stays the same.

RemoveRegistry table I have never used will give it a go.

No there was no shortcuts taken something in one of the old installers has caused the problem.

Thanks that worked. I also had to add an entry to the registry table.

when doing the major upgrade it should remove all of the files and reinstall. That depends on where the RemoveExistingProducts action is sequenced, though, doesn't it? MS recommends that it goes right at the end, to reduce the overhead of removing and then installing files which haven't changed (even a major upgrade would probably have files in common with the older version).

On some upgrade MSIs I have had to bump up the RemoveExistingProducts sequence to 1510, which should be right after InstallInitialize. The reason I had to do this was because of unversioned files. Here is a good read on the MSI upgrade rules for versioned, unversioned files if you're interested.

The reason behind this problem is due to the change in Component GUID from lower version of app to higher version of app. This problem will occur for the files that are installed to Shared locations such as Windows, System32, Common files Folder etc..

To resolve the issue:

1. Copy the GUID of the component of the file in older version of the Application and replace the GUID of the component in the higher version of app for that respective file.

This will resolve the Issue in most of the cases.

Any suggestions are Welcome.

to bump up the RemoveExistingProducts sequence to 1510, which should be right after InstallInitialize. The reason I had to do this was because of unversioned files.
which in this case would not help as it would perform the uninstall, bump down the sharedDLL count, but the file would still remain resident & not be removed or overwritten.

Although I agree with you that it is sometimes advisable to move the RemoveExistingProducts up (I typically move to 1475 b4 InstallInitialize) especially if you have no control over the upgrade path & have not performed things like component matching between the 2 MSIs...