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

Major Upgrade


9 replies to this topic

sebica79

sebica79
  • Members
  • 62 posts

Posted 14 November 2005 - 14:22

Hi there,

I'm coming with some issue related to major upgrade.

I have created a major upgrade from Upgrades tab. During creation, I have modified the product version – correctly - , the product code and the package code.

Now the problem is that the uninstall of the previous product is made correctly, but the install does not. It is installed only the binaries which their versions has been changed. Is this an InstallShield 11 limitation (Basic MSI Project)? Do I have to change the version for all the binary files?

Thank you,
Sebastian




Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 14 November 2005 - 15:28

Are the missing components set o "never overwrite"?

sebica79

sebica79
  • Members
  • 62 posts

Posted 14 November 2005 - 15:52

Hi Stefan,

Thank you for the reply.
Actually, for all the components, the flag is set to "No". As far as i know, this property is available when the file is already installed, or already exists on the target machine. In our case, the major upgrade is performed which means that, first, the old product is uninstalled, right? That is why I did not give attention to this.

Thank you,
Sebastian


sebica79

sebica79
  • Members
  • 62 posts

Posted 15 November 2005 - 11:56

Can be another reason for this behavior?

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 15 November 2005 - 17:42

There's a known issue with Never Overwrite in Major Upgrades, but your problem seems to be different.
Generate a verbose log of the update and look at the component and feature states, and for the overwrite information for the files in question.

sebica79

sebica79
  • Members
  • 62 posts

Posted 16 November 2005 - 17:02

Hi Stefan,

Related my problem, I have read the following thread:
http://forum.install...showtopic=7730;
It seems that the reporter does know very well that, his binaries were newer than the original package. In my case, if those binaries has a newer version than the original package, it seems to work (they are installed). Why I said that, it seems, because I did not rebuild all the *.msm files yet, which corresponds for all the changed *.dll block versions.
I will change the *.dll’s version and I will let you know, exactly, what is the scenario for good working.
I’ll let you know if I’ll change the block version it will work fine.
Anyway … does not sound great that, if you leave unchanged some components, those were not installed after the old version is uninstalled.

I have pasted some lines form the log file:

MSI (s) (28:E8) [10:35:24:566]: Disallowing installation of component: {7D567550-CB16-4D8B-BE86-4C1F5023F5FF} since the same component with higher versioned keyfile exists;

MSI (s) (28:E8) [10:35:25:004]: Component: xxxxxxxxx.D3A099C9_3749_47BB_8526_3B399AAFAFC5; Installed: Absent; Request: Local; Action: Null

MSI (s) (28:FC) [10:35:27:520]: Disallowing uninstallation of component: {138AFF35-5675-11D7-8B4B-00105A9846E9} since another client exists;

Thank you for your patience.


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 16 November 2005 - 18:18

QUOTE
MSI (s) (28:E8) [10:35:24:566]: Disallowing installation of component: {7D567550-CB16-4D8B-BE86-4C1F5023F5FF} since the same component with higher versioned keyfile exists;

So your new setup includes an older version of this file. (Look up the key file for the component with that GUID in Orca).
QUOTE
MSI (s) (28:E8) [10:35:25:004]: Component: xxxxxxxxx.D3A099C9_3749_47BB_8526_3B399AAFAFC5; Installed: Absent; Request: Local; Action: Null

That doesn't look right. Request and Action should ususally be the same.
QUOTE
MSI (s) (28:FC) [10:35:27:520]: Disallowing uninstallation of component: {138AFF35-5675-11D7-8B4B-00105A9846E9} since another client exists;

This is a shared file. Another MSI package has also installed this file.

sebica79

sebica79
  • Members
  • 62 posts

Posted 18 November 2005 - 16:42

Hi Stefan,

I have made some tests and here are the results:

Related to:

MSI (s) (28:E8) [10:35:24:566]: Disallowing installation of component: {7D567550-CB16-4D8B-BE86-4C1F5023F5FF} since the same component with higher versioned keyfile exists;

It seems that you’re right, the components in questions have a older key version that the ones form the original package – this problem has been fixed by correcting the key files with the latest ones – the problem was that I built locally the components, and my files weren’t up-to-date.

Related to:

MSI (s) (28:E8) [10:35:25:004]: Component: xxxxxxxxx.D3A099C9_3749_47BB_8526_3B399AAFAFC5; Installed: Absent; Request: Local; Action: Null

I think that the Action is “Null” because, after the installer executed the MigrateFeatureStates which reads the feature states in the existing application and then sets these feature states in the pending installation. With other words, in our case, based on existing product, settings for features states which have the key files were set up to ‘Local” but the Action is “Null”. It doesn’t matter what values have the properties for feature installation or something related.

As we already know, the CostFinalize action, determines which feature must be installed, and in our case I think the features which contain components that have the same key file as the original package has, do not get installed at all.

As a conclusion, I don’t know why and when the values for Request and Action may differ.

Related to:

MSI (s) (28:FC) [10:35:27:520]: Disallowing uninstallation of component: {138AFF35-5675-11D7-8B4B-00105A9846E9} since another client exists;

It’s not actually a bad thing, as far as I observed because I have seen that it applies for those components that do not have much things to do with the original package.

For example, Global_System_STDOLE.8C0C59A0_7DC8_14D5_B95D_006097C4DE24, or stuff related to Live Update services, and the examples can continue.

Having said that, it seems that is something wrong with the Windows Installer Engine. This is not good at all.

In addition, I think that the only reliable option, without any other bad results, which would imply modification in install sequence, would be to change the block versions for the binaries files.

Many thanks, any ideas are welcomed!

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 20 November 2005 - 18:02

You could try chaning your Major Upgrade settings to perform an in-place upgrade instead of an uninstall-old-then-install-new.

sebica79

sebica79
  • Members
  • 62 posts

Posted 21 November 2005 - 10:12

Hi Stefan,

I have tried to make some tests again, with different settings related to Major Upgrade.
I have made actually test with all the Major Upgrade Styles, but those lead at the same conclusion, some components are not copied or are deleted.
If I try to apply, the upgrade set up at “Install and then remove unused files” the same things is happened, some files are missing, and I think they are deleted.

Best regards,
Sebastian