1

We use a managed bootstrapper.

We have two products in our bundle (let's call it BundleName) - ProductA and ProductB. We install both products and it works fine.

Next we change a version of BundleName from 1.0.0.0 to 2.0.0.0 and the MSI version of ProductA from 1.0.0.0 to 2.0.0.0.

Performing upgrade. It completes successfully but in the log of BundleName 1.0.0.0 (previous version of bundle that should be uninstalled) we have:

Will not uninstall package: ProductA, found dependents: 1
Found dependent: {ffe63ad2-5155-4958-91cc-b0aac330cdb6}, name: BundleName
Will not uninstall package: ProductB, found dependents: 1
Found dependent: {ffe63ad2-5155-4958-91cc-b0aac330cdb6}, name: BundleName

Nevertheless, it works fine.

The problem appears when we remove the upgraded 2.0.0.0 BundleName. The bundle removes it successfully and logs are clear, but it does not remove any files and registry keys of ProductA.

One more thing we noticed in 2.0.0.0 logs also a bit strange:

Planned package: ProductA, state: Present, default requested: Present, ba requested: Present, execute: **MinorUpgrade**, rollback: None, cache: Yes, uncache: Yes, dependency: Register

We changed the first number of version, so it should be MajorUpgrade not MinorUpgrade.

Here is our configuration:

<Product
   Id="$(var.ProductCode)"
   UpgradeCode="$(var.UpgradeCode)"
   Name="$(var.ProductName)"
   Language="1033"
   Version="$(var.ProductVersion)"
   Manufacturer="$(var.Manufacturer)">

<Upgrade Id="$(var.UpgradeCode)" />
<MajorUpgrade DowngradeErrorMessage="A newer version of $(var.ProductName) is already installed." 
              Schedule="afterInstallInitialize"
              AllowSameVersionUpgrades="yes" />
...

Could somebody please explain what we missed out?

Veikedo
  • 1,453
  • 1
  • 18
  • 25

1 Answers1

1

Found the problem. ProductCode in Product element was fixed, not *.

How To: Implement a Major Upgrade In Your Installer

How To: Generate a GUID

Veikedo
  • 1,453
  • 1
  • 18
  • 25