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

In Upgrade: some components upgrade


4 replies to this topic

MikeBergman

MikeBergman
  • Members
  • 27 posts

Posted 14 January 2005 - 22:01

I have authored an MSI project which should run as a clean install or an upgrade. I have taken the setup.exe project from Microsoft's Platform SDK and I have modified it slightly to allow for logging and to fix a problem with using the OPERATION resource and allowing command line parameters at the same time. None of this should have any effect on the problem; I only mention it to give context to how I executing the msi file.

The problem is this:

I have three installations: 5.1.759, 5.1.758, and 5.0.783. I want to upgrade 5.1.758 and 5.0.783 to 5.1.759 or install 5.1.759 as a new install.

Installing 5.1.759 as a new install works correctly.
Upgrading 5.1.758 to 5.1.759 also works correctly.
Upgrading 5.0.783 to 5.1.759 has mixed results! Some components get upgraded while others do not. All executable components (exe and dll) are versioned.

I created a couple of upgrade logs for the 5.1.758->5.1.759 upgrade and 5.0.783->5.1.759 upgrade.

In both cases REINSTALLMODE = vomus and REINSTALL = ALL.

In the 5.1.758->5.1.759 upgrade log I found the following line:

MSI (s) (E0:98): Component: AS_Config.exe; Installed: Local; Request: Local; Action: Local

and in the 5.0.783->5.1.759 upgrade log I have the following line:

MSI (s) (D4:B8): Component: AS_Config.exe; Installed: Local; Request: Null; Action: Null

each component which upgraded showed Local for Request and Action and each component which did not showed Null for those items. I assume the Action is Null because the Request is Null so my question is why is Request Null? Is there any place else I can look for a clue as to why this is happening?

I should mention that all of this is using MSI 2.0 and I am prototyping basic msi projects using InstallShield Developer 7.0.2.

thanks
michael bergman

Edited by MikeBergman, 15 January 2005 - 00:19.

Michael Bergman
LumenVox LLC

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 17 January 2005 - 08:50

First, search your log file for SELMGR messages.
Then, in a verbose log, you should see detailed information for each file and component as to whether it will be overwirtten, or not, and why.

MikeBergman

MikeBergman
  • Members
  • 27 posts

Posted 18 January 2005 - 18:45

MSI (s) (D4:B8): SELMGR: ComponentId '{16D62E7F-5D7D-48E8-A272-89377B1B850F}' is registered to feature 'ArtiSpeech', but is not present in the Component table. Removal of components from a feature is not supported!
MSI (s) (D4:B8): SELMGR: Removal of a component from a feature is not supported

Okay, well, I think I understand what is going on here... if I have a component that is obsolete, can I maintain the component without maintaining the file (not include the old file as part of the component)?
Michael Bergman
LumenVox LLC

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 19 January 2005 - 10:39

Yes, if the file is not the key path of the component.
Otherwise leave the component as is (or replace the file with a small dummy file of the same name if size matters), and set the component condition to 0.

MikeBergman

MikeBergman
  • Members
  • 27 posts

Posted 19 January 2005 - 19:17

Okay, I should explain what happened here in case someone else runs across this problem:

I have product called Installation_X which has a version 5.0.100 and it has been released to the public. We have branched the code in our code repository so that there is a new version, 5.1.100. At this point, version 5.0.100 and 5.1.100 are identical.

I now get a request to add Component_Y to Feature_Z in _both_ versions. So I create the component in each of the installations, 5.0.100 and 5.1.100. The problem is that I am not paying attention to the fact that Component_Y in 5.0.100 has a different Component Code from the the one in 5.1.100!

Because the component codes are different, but the component names are the same, MSI cannot resolve it so it does not upgrade the entire Feature_Z.

The upgrade 5.0.100 -> 5.0.101 works because the component code is the same for all installations in the 5.0 branch.

The upgrade 5.1.100 -> 5.1.101 works because the component code is the same for all installations in the 5.1 branch.

The upgrade 5.0.100 -> 5.1.101 does not work because the component code is different between the two versions.

The solution is to make sure that the component codes are the same across all versions.

I hope that is clear enough. If you have any additional questions, just hesitate to ask.



Michael Bergman
LumenVox LLC