Problem overwriting existing files on minor upgrade

[Magnus]

In my upgrade (InstallShield 2010, Basic) I'm setting REINSTALLMODE to vamus and REINSTALL is already set to ALL.

The thing is that it doesn’t overwrite the existing files in one specific directory. They aren't read-only and thera are no processes running that could cause that the file is used, and I'm using vamus.

I checked the log and found the following: se for example

[10:09:14:115]: Component: PDCColumnIndividual.dll; Installed: Local; Request: Null; Action: Null

If I manually delete the files in that directory prior to running the upgrade, they get replaced with the proper files when I run the upgrade, but if I don't delete them they don't get overwritten.

Please help!

[Lurean]

Are the files in question versioned files? And are the version numbers different?


Is there a key file selected for the component that installs those files in the original installer? Is that Key file being replaced with a newer version?

These are things to check on, since they will impact how files are replaced on a given system.

[Magnus]

Hi, thanks for the response.

[Lurean]> Are the files in question versioned files?
Yes, the dll files are .Net dlls and got both "Product version" and "File Version"

[Lurean]> And are the version numbers different?
Yes, old version is: 6.0.14.18 and the new version is 6.1.101.3

[Lurean]> Is there a key file selected for the component that installs those files in the original installer?
Yes, all dlls are marked as a key file. I have one component for each dll file and the dll-file is the only file in that component.

[Lurean]> Is that Key file being replaced with a newer version?
Yes.

BR
Magnus

[Reureu]

Hi,

Just a few questions:

• Have you got any dynamic link in the same feature as this component?
  
• Have you tried the Upgrade Validation Wizard? Does it return any warning or error?
  

Regards

[ericpaul]

Hi, another possibilty is that you have (accidently) set the component's Never Overwrite property to Yes.
In that case, the corresponding file will not be overwritten.

[Magnus]

Yes, I got some dynamic links in the feature XClient. In the upgrade version I have removed all dynamic links. The Upgrade Validation wizard aslo complains on some removed files that are removed in the newer (upgrade) version (I’ve not added those files in the Direct Editor Table – RemoveFile). When running the upgrade I got “XClient; Installed: Advertise” on the feature where no files are upgraded.


MSI (s) (B0:F4) [14:33:14:683]: Feature: Database; Installed: Local; Request: Reinstall; Action: Reinstall
MSI (s) (B0:F4) [14:33:14:683]: Feature: XClient; Installed: Advertise; Request: Reinstall; Action: Reinstall
MSI (s) (B0:F4) [14:33:14:683]: Feature: InstallationSupportFiles; Installed: Local; Request: Reinstall; Action: Reinstall
MSI (s) (B0:F4) [14:33:14:683]: Feature: InstrumentServer; Installed: Local; Request: Reinstall; Action: Reinstall
MSI (s) (B0:F4) [14:33:14:683]: Feature: LicenseServer; Installed: Local; Request: Reinstall; Action: Reinstall

Is it maybe the “Advertise” thing that causes this problem and if so how can I fix this?

[Reureu]

This is one side effect of dynamic links: if some files have been removed, you won't see it when building the MSI package.
Then you install your new package, a minor upgrade takes place and the feature that contained these dynamically linked component gets somewhat broken on the target PC. Hence, the files that should be upgraded are not replaced. The logfile says the corresponding feature is advertised.

You have several possibilities to solve that problem:

• Avoid using dynamic links. You say you have done that already. But if your previous package has been released already, you are in trouble.
  
• Find which files have been removed, and add them to the RemoveFile table. If the removed files were dynamically linked, then the file ID's and the corresponding component ID's have been randomly generated. Which means zhey are nightmare to enter in the RemoveFile table. So that is not applicable with dynamic links in reality.
  
• Forget the minor upgrade, and configure the Upgrades view to perform a major upgrade. This is the solution I would recommend.
  

Also I would recommend you to avoid dynamic links in the future. They might look like a rather practical solution, but they can have evil side effects, as you have seen.

[Jeff2008]

Yeah, happened to me too, you're kinda forced to do a major upgrade. I've founded this post usefull (especially the trick about the MSIENFORCEUPGRADECOMPONENTRULES property).

[Magnus]

I have now verified that it was the dynamic files that caused this problem. Thank you all!!

Best Regards
Magnus