Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Files are not getting updated during patch install


12 replies to this topic

subodh_jai

subodh_jai
  • Full Members
  • 17 posts

Posted 06 April 2010 - 14:36

During installation of our patch (.msp), some of files are not getting updated on the target system. These files are exe files and is of the latest version but still its not getting reflected on the target system and still the file on the target system points to the older version.

These files are authored in the updated msi by adding a new component in the existing feature and also by updating the existing component to point to a new file version and then getting the .msp between the base and the updated .msi


Approaches already used:

1) Used File versioning using the following methods:

Author the File table in the Direct Editor for the files to be replaced in the patch with the latest version.
Checked the “Overwrite system version property” for the file in the component view

2) Used the "Include whole files" build setting option of the advanced tab of patch design view.

Set the "Include whole files" property to "Yes" in the build settings of the "Advanced" tab of the patch design view.

3) Setting the components "Shared" property to "No".

One of our existing component has Shared set to Yes. Now this component is updated by our patch to point to a new version of the exe. We tried building the updated .msi file by setting the shared property to "No" but still the new file(authored by the component) did not copy to the target system.

Please advice what will be worng here.


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 08 April 2010 - 16:43

I don't fully understand what you are doing. Why are you adding components?

Did you generate a log file? Look for SELMGR errors in the log.

VBScab

VBScab
  • Full Members
  • 436 posts

Posted 09 April 2010 - 10:55

QUOTE (Stefan Krueger @ 2010-04-08 16:43)
Why are you adding components?

Stefan, my reading of it was that the OP is using the MSI==>MSI delta method of creating a patch. I figure the new MSI has the new components and is then compared to the old MSI.
- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 09 April 2010 - 11:43

Adding new components for (the newer version of) an existing EXE would certainly be a problem. However what confuses me is:
QUOTE
adding a new component in the existing feature and also by updating the existing component to point to a new file version

The latter (using the newer EXE in the existing component) would be the correct way.

subodh_jai

subodh_jai
  • Full Members
  • 17 posts

Posted 10 May 2010 - 10:43

Sorry for being very short earlier, please find the description below.

Problem Description:

We have some exe files in one of our installers. These exe files are authored as separate components in the “Setup Design” in Install shield. Each one of these exe is the key file of its respective component. All these components fall under a Feature ( say F1) which is conditioned to run for a particular type of node. All these files are statically linked to the components. Now when we update a component under the Feature F1 ( so that it points to the latest version of an exe file) and draw a patch( .msp) from the updated and base installers and installs it, then the latest version of exe is not getting updated on the target system.

We have already verified that the condition for the Feature F1 is met and it is marked for installation. Also the version of the file being installed by our patch is higher ( 400.0.84.3) as compared to the version of the file on system (400.0.84.0) still the file on the target system is not getting updated. This is totally opposite to the “File Versioning Rules” of windows installer.

Also the file of the target system has same modified and creation date. So here we can easily rule out the fact that file with the latest version was not copied on the target machine to preserve the user data.


Options Already tried\Known:

1) Authored the File table with the version of the file being installed by our patch (400.0.84.3) – Tried it out but is not working.
2) Checked the “Always Overwrite” property of the file – Doesn’t sound like a good option because we need to check this property individually for each and every file.
3) Checked the “Overwrite System Version” property of the file – Tried it out but is not working, this internally authors the File version column of the File table.
4) Delete the file on the target system first and then try to install it – Doesn’t look like a good option.
5) Used REINSTALLMODE=amus REINSTALL=ALL during patch installation – Tried it out but is not working.


VBScab

VBScab
  • Full Members
  • 436 posts

Posted 10 May 2010 - 11:54

I *think* I'm right in saying that, in Windows Installer, file version checks are only carried out on the 'major.minor.build' parts of a version number. The 'Revision' part is ignored. Thus, a change from 400.0.84.0 to 400.0.84.3 will be treated as unchanged.

To be acted upon, the version would need to change to 400.0.85.0.
- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 10 May 2010 - 15:04

QUOTE
in Windows Installer, file version checks are only carried out on the 'major.minor.build' parts of a version number
No, that's only true for the ProductVersion. For file versions all four fields are evaluated as far as I know.

Steps to diagnose the problem:
- perform patch validation (if your tool has this option)
- generate a verbose log of the patch install
- look for SELMGR errors in the log
- check the log entries for the affected files, components and features. It should tell you whether they are selected and why they aren't copied over (the log will include information about the result of the version comparison etc.)

snip

snip
  • Full Members
  • 4 posts

Posted 18 January 2011 - 16:37

Hi Stefan,

Sorry for not updating this post for a very long time rather. We are stilll having this issue.

- We have generated verbose log for the issue and found out that window installer is not considering the Feature to be reinstalled

Feature: Installed: Local, Request: NULL, Action: NULL

I have verified that the Feature condition is satisfied but still the feature is not considered for installation. All the files under this feature are not getting copied over to target system.

We dont have any SELMGR error in the verbose logs.
What can be reason for the Feature not getting resintalled during the MSP patch installation.

Regards
snip

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 18 January 2011 - 17:00

What's the value of the REINSTALL proeprty in the log?

snip

snip
  • Full Members
  • 4 posts

Posted 19 January 2011 - 06:00

Stefan, Thanks alot for a prompt reply.

The value of the REINSTALL property is only set to feature being reinstalled.

REINSTALL='COMMON'. Here COMMON is a feature in our installation package and the InstallValidate has the following line for this feature.

FEATURE: COMMON Installed: Local, Request: Reinstall; Action: Reinstall.

and hence very correctly the value of REINSTALL is only set to COMMON feature. Now i fail to understand here that why the REINSTALL property is not having the name of the other feature ( we call it Process_Server in our installation package) even though we have updated components in this features also.

This feature (Process_Server) has 2 components with Dynamic Link ( other componets have key files and are statically linked) but include no subfolders. As a check i even updated these 2 components to have one file statically linked and this file is made as KeyFile of the component. Other files are Dynamically linked with Include subfolder option unchecked. ( find the image attached)



Even with this change, there is no request for feature and the component to be reinstalled on patch installation.

Regrads
snip




Attached Images

  • Image.JPG


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 19 January 2011 - 10:00

QUOTE
This feature (Process_Server) has 2 components with Dynamic Link ( other componets have key files and are statically linked)
I'm not sure but this might be the cause for the problem.

QUOTE
As a check i even updated these 2 components to have one file statically linked and this file is made as KeyFile of the component
You can't do this in a minor update. This is a change that would require a Major Upgrade.

snip

snip
  • Full Members
  • 4 posts

Posted 19 January 2011 - 15:07

Stefan, thatnks alot for all ur help on this topic but i still have some doubts.

I again changed my base MSI and now there are no Dynamically linked components in the feature ( Process_Server). Still the patch is not working and the feature's installation request is NULL

FEATURE: Process_Server, Installed: Local, Request: NULL, Action: NULL

No clue what is happening here. Now all the components are statically linked to files and also have Key files.

My file are versioned like 410.0.31.0 ( Base MSI) and 410.0.32.0 ( For updated MSI), can this be the cause of issue. Will windows installer consult all the four fields here or not ( I guess a yes here, its only for Product Version that 3 octet rule is applicable)?


Can someone please let me know what rule windows installer uses to know if has to install the FEATURE or not? I know the rule for component installation is the Key path.

Regards
snip.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 20 January 2011 - 18:29

QUOTE
Will windows installer consult all the four fields here or not ( I guess a yes here, its only for Product Version that 3 octet rule is applicable)?
Yes, that's correct.

Do you launch the patch by double clicking the .msp file or using an update.exe? Does the patch work in silent mode (/q)? I wonder if either the update.exe or a dialog butten is setting the REINSTALL property to a wrong value.

But again: if you changed the key file, you can't create a minor update patch.