Understanding Patch Image Hierachy

[clint]

I am trying to understand how to do this properly and the correct hierarchy use.

Each time I need to create a new patch, I first create a new package for the Product, only swapping out the older files with newer ones, the I changed the Product version, and when asked "Major Upgrade" or "Patch" I select "Patch.

Then I create a new Patch project, and under "Images" select the new package as the "New Upgraded", and add all the previous versions with "New Target"

I want that each new package version for the Product which a new customer installs for the first time, to be able to be updated by this patch:

• Customer A Installs for the product first time using Target 1.0.0
  Customer A Installs Upgrade Patch 1.0.4
  
  Customer B Installs for the product first time using Target 1.0.2
  Customer B Installs Upgrade Patch 1.0.4

Now, both customers should be using the same product with the same changes

In my patch aip, the "Images" section looks like this:

• Target Computer
  • - Family 1
    • - Upgrade 1.0.4
      • - Target 1.0.0
        - Target 1.0.1
        - Target 1.0.2
        - Target 1.0.3

I am assuming this is all correct. It seems however to work properly.
I applied this patch to both customers and the newer files in Upgrade 1.0.4 replaced the older ones.

What I don't understand, is what the following structure would be for, and why this would be someday needed (and when I did try to do it like one of the two examples following, either the files do not update properly, or the build errors out when creating the patch)

• Target Computer
  • - Family 1
    • - Upgrade 1.0.3
      • - Target 1.0.0
        - Target 1.0.1
        - Target 1.0.2
    • - Upgrade Patch 1.0.4
      • - Target 1.0.3

or this:

• Target Computer
  • - Family 1
    • - Upgrade 1.0.3
      • - Target 1.0.0
        - Target 1.0.1
        - Target 1.0.2
  • - Family 2
    • - Upgrade Patch 1.0.4
      • - Target 1.0.3

AI help files seems to only explain only a very first patch.

In the last two examples, could someone please explain how to apply and what should be taking place in these scenerios?
Or, at least first of the two, assumming the second is nothing more than an extension of the logic which is behind the first.

Thank you,

clint

[Eusebiu]

Hi Clint,

I am assuming this is all correct. It seems however to work properly.

Yes, indeed all the steps you described above are correct.

In the last two examples, could someone please explain how to apply and what should be taking place in these scenarios?

Unfortunately, the first of your examples does indeed throw an error at build time because Windows Installer does not support this scenario. We will improve this in the future so that this configuration will not be allowed.

The second example creates a patch for two different families (products). In this case when the patch is launched, it searches if at least one of the products is installed on the machine:
- if none is installed the following error is thrown: "The upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded may be missing, or the upgrade patch may update a different version of the program. Verify that the program to be upgraded exists on your computer and that you have the correct upgrade patch."
- if only one product is installed, the patch will run and install the modified/additional files only for the installed product, then it will stop
- if both products are installed on the machine, the patch will run and install the modified/additional files for the first product, then for the second product

Let us know if this helped.

Best regards,
Eusebiu

[clint]

Hi Eusebui,

Yes, indeed all the steps you described above are correct.

Fantastic! Thanks!

Unfortunately, the first of your examples does indeed throw an error at build time because Windows Installer does not support this scenario. We will improve this in the feature so that this scenario will not be allowed.

Happy to know to ignore this scenerio! Thanks for explaining!

The second example creates a patch for two different families (products)

Oops. I guess I was equating different "Product-Families" with different "Product-Codes" of the same Product-Family.
But, that (the latter) could be the case too, if this scenerio would be used to update two side-by-side installed versions (different product codes, but the same Product-Family, each with their own set of patches) as well, right?

Thank you!

clint

Edit: A "Family" would then identified by the unique Upgrade-code?

[Eusebiu]

Hi Clint,

Oops. I guess I was equating different "Product-Families" with different "Product-Codes" of the same Product-Family.

Sorry, it seems that I made a mistake here. Indeed, different "Product Families" means different "Product Codes", not different "Upgrade Codes".

But, that (the latter) could be the case too, if this scenerio would be used to update two side-by-side installed versions (different product codes, but the same Product-Family, each with their own set of patches) as well, right?

Yes, this scenario can be used to upgrade two side-by-side installed versions of the same product.

Best regards,
Eusebiu

[clint]

Understood! Thanks!

I guess the easiest way for me to understand it, is with the example of a side-by-side installation of the same Product, but different Product-Codes (and Versions):

Product: Installation for MyAppTest Upgrade code {E13E4450-525B-4758-AF3B-9448D6FA5B30}

• - Family 1 Product Code {6C64B773-76C5-4C33-8F18-85C0684E1F12} (MyAppTest Version 1)
  
  • - Upgraded MyAppTest v.1 v.1.0.4
    • - Target MyAppTest v.1.0.0
      - Target MyAppTest v.1.0.1
      - Target MyAppTest v.1.0.2
      - Target MyAppTest v.1.0.3

• - Family 2 Product Code {09AC9581-9FD4-4108-AEF2-1B70A6AF4550} (MyAppTest Version 2)
  
  • - Upgraded MyAppTest v.2.0.4
    • - Target MyAppTest v.2.0.0
      - Target MyAppTest v.2.0.1
      - Target MyAppTest v.2.0.2
      - Target MyAppTest v.2.0.3

I guess this is correct.

Thank you!
Clint

P.S.: Any chance of in the Image section, allowing a longer name for the Family, such as a Product code (doesn't appear do be used as an image folder name)?

[Eusebiu]

Hi Clint,

I guess this is correct.

Yes, this is correct.

P.S.: Any chance of in the Image section, allowing a longer name for the Family, such as a Product code (doesn't appear do be used as an image folder name)?

I'm afraid that this is a Windows Installer limitation.

Best regards,
Eusebiu

[clint]

Thank you!

I'm afraid that this is a Windows Installer limitation.

Then how about as a Description block (for version info, product/package codes, descriptions, info) on the "Image Family Properties" register, the "Image Upgrade Properties" register and the "Image Target Properties" register?

Would help identifying the underlying source files, in case they are missing, or the aip project is moved, and would help in identifying the hierarchy structure easieier.
As it is, all that I have to go by, is a short name, and the underlying folder names.

Thank you!

Best regards,

Clint

[Eusebiu]

Hi Clint,

I added this improvement on our TODO list and it will be available in a future version of Advanced Installer. Thank you for your suggestion.

Best regards,
Eusebiu

[clint]

Fantastic!

Thank you!

Clint

[Eusebiu]

You're welcome.

Best regards,
Eusebiu