4 replies to this topic

[dbareis]

Hi,

I have a simple requirement for use in a controlled environment. When I click on an MSI (that I create) it installs. If there is an existing (or same, or greater) version of the package it is first uninstalled.
We use all 4 available parts in the version number.

I have tried by fixing upgrade codes and changing all others and then using the Upgrade Table and moving the documented CA to force early uninstall, but either this does not work correctly unless major/minor parts of version numbers change or there is a bug somewhere (some files don't get installed, OK after a self repair!), in any case it does not handle the same MSI being installed. If package Netdeployed over previously manually installed it also fails.

I am getting sick of seeing multiple packages installed for applications where this is impossible and only stuffs everything up.

I am thinking about creating registry entries keyed by upgrade code to store the information required to remove the package but am unsure about where I should put the custom action to do the detection/uninstall (it also should not try an do any processing on package removal (prevent infinite loop).

Thanks for any ideas.

[Tom]

If you've got everything else correct, just leave the version fields blank in the upgrade table and you're set.

What I do:  (capitalization is important within the tables)

Upgrade Table:
1. Upgrade code in upgrade table (of course)

2.  _NO_ versions listed in versionmin or versionmax

3.  '769' in attributes ('1' would be adequate in this case.  768 = 256+512 = 'include' the min and max versions for upgrade - default is to exclude the actual versions specified)  Adding 1024 will make it do all languages.  We only build for English here.

4.  ActionProperty is 'APPUPGRADE'

In Property table:
Property 'SecureCustomProperties'  is set to 'APPUPGRADE'

Every build:  Package Code and Product Code must be unique.  UpgradeCode must never change.

Almost forgot - don't need a custom action, but you should probably bump the 'RemoveExistingProducts' action up so it falls between InstallValidate and InstallInitialize

(Edited by Tom at 1:42 pm on Aug. 10, 2001)

[dbareis]

Thanks for the reply, I did some more testing and now can't get it to fail. I spent a large amount of time on Friday trying different things to see if it would. I know it does sometimes fail... I have seen it do so (but on different machine). MSIEXEC /? shows same version number on both machines.

I pretty much do what you do, not sure about (3), I will check.  And I do not have the property added to "SecureCustomProperties" which I had also picked up. I really don't want to make changes until I can reliably get it to fail (then I will know if I have fixed it), I suppose I may have to fix it and watch...

[Tom]

Well, if you want it to fail...

Trying to 'upgrade' (and not patch) when changing the package code without changing the product code will give an error that another version is installed and must be removed first...

If you try to upgrade from version 1.0 to version 2.0, and your min/max versions in the upgrade table say 1.0 and 2.0 and you only have 1 or 1025 in the attributes, that will refuse to upgrade because "1.0" is not included in the range of "between 1.0 and 2.0"...

What _exactly_ failed previously?

[dbareis]

Hi,

I don't want to fail but unless I can reliably reproduce the problem I have no way of knowing that I have solved it...

I have blanks for min/max and WAS using 0 for the attributes, I have now changed this to 0+256+512+1024 (even though I only use one language - english). I did NOT add attribute "1" as I don't think any migration of any type is involved with uninstall???

My packages are automatically created from scratch each time. The only code I "fix" is the upgrade code, so there is no possibility of the other codes not changing.

I have seen two different things happen (I have been concentrating on (2) as I don't have test environment for (1) - with any luck the 2 are related anyway):

 (1) End up with multiple packages installed.
       This I have seen after manual install of package
      (logged on as administrator)  and then same
      package  NetDeployed. Could be NetDeploy
      feature...

 (2) ONE of my files (a keyfile of a component if that matters) is missing after the uninstall/install. So a self repair happens when I click on the shortcut to it. This I have seen when manually installing (logged on as administrator) the packages (DetDeploy not involved).

This is the complete code I use for the upgrade logic (formatting may be off a bit and I have used Wise/Orca to double check all steps correctly applied):

  ;--- Look for older/newer versions of the same package (group) -----------
  <$HereWeAre "Setting up to automatically uninstall existing packages.">
  #define PROPNAME_OLD_PROD_CODES OLDPRODUCTCODES
  <$TABLE "Upgrade">
      #(
      <$Row
              UpgradeCode=^<$BSD_UPGRADE_CODE>^
               Attributes=^<$VbImbed Stat="256+512+1024">^
                   Remove="ALL"
           ActionProperty="<$PROPNAME_OLD_PROD_CODES>"
      >
      #)
  <$/TABLE>

  ;--- Want any existing version fully removed prior to install of new package! ---
  <$TABLE "InstallExecuteSequence">
      <$Row "RemoveExistingProducts" Sequence="1450">
  <$/TABLE>

  ;--- Add the "UPGRADE" property to secure custom properties value --------
  dim SecureCustomProperties
  SecureCustomProperties = <$WiseObj>.GetProperty("SecureCustomProperties")
  if  SecureCustomProperties = "" then
      SecureCustomProperties = "<$PROPNAME_OLD_PROD_CODES>"
  else
      SecureCustomProperties =
                      SecureCustomProperties &
                     ";<$PROPNAME_OLD_PROD_CODES>"
  end if
  <$HereWeAre "Updating 'SecureCustomProperties'.">
  Ok = <$WiseObj>.SetProperty("SecureCustomProperties", SecureCustomProperties)
  <$DieIfNotOk>