Patch Looking for source file

[vidur]

Hi,
Scenario:
Created installer package with advanced installer. Use deployment tools to deploy the product. It works fine
-When i try to apply a patch. It fails (it seems the patch is looking for the source file) and cant find it.

I tried this manually where i installed the product on the PC, then i deleted the MSI. And tried to patch it. The patch fails and says can not find the resource. But when i try to uninstall its still okay.


Is there anyway i can patch without using the the original resource file (as i know windows makes copies of the package and that's where it uninstalls from .

Thanks

[Daniel]

Hello,

This may happen if when the patch is applied it needs to access a resource from the CAB. Please keep in mind that at install time Windows Installer caches the MSI installation database in the "Windows\installer" folder, but it stripes down the CAB within the MSI (for size reasons). Then, during the repair operation if a resource from the CAB it's required Windows Installer will prompt for original setup installation.

If your target installation setup is an EXE setup, in order to avoid this problem, you can select the "Do not delete extracted MSI and CAB files" option from "Media" page -> "Configuration" tab.

Let us know if this helps, otherwise please give us more details about your installation scenario. If you could isolate the behavior in a buildable sample (AIPs + its referenced files) and send it us so we can test on our side this will be very useful.

All the best,
Daniel

[vidur]

Hi,

I am using MSI type package. heres the scenerio to follow.

1.) Create an application package in MSI build (version 1.0.0.1)
2.) install applciation
3.) Create minor update of the applcaiton using MSI build (version 1.0.0.2)
4.) create a patch with 1.0.0.1 to 1.0.0.2
5.) Delete the source msi of 1.0.0.1
6.) Run the patch
It will fail

Please find a sample test AIP and patch AIP attached to the comment

[Daniel]

Hello,

I've tested the scenario and, indeed I can replicate the behavior. This happens because patch packages created with Advanced Installer set the "REINSTALLMODE" property to "ecmus" during patch installation. This is our default implementation.

"e" means that a versioned file will be always reinstalled if the file is missing, or is an equal or older version. So, the patch will try to reinstall all components containing versioned files whose installed version is older or equal with the file version contained by the current MSI database. But, if the above files won't be contained by the patch setup, then Windows Installer will try to access them within the CAB file included in the original MSI database.

In order to avoid this behavior, as a workaround, you can launch your patch installation using a command line like this:

Code: Select all

msiexec.exe /p "<path_to_patch>MyPatch.msp" /qb REINSTALLMODE="omus" REINSTALL="ALL"

Also, as a side note, please keep in mind that Windows Installer ignores the fourth field of the ProductVersion. So, you should set the product versions of your target and upgraded setups accordingly.

If you have any questions let us know.

All the best,
Daniel

[vidur]

Hi,
Thanks for the reply dan.

But it still doesnt work, if the source msi isn't there, i can not patch it

And yes i am aware of the windows ignoring the last version number. But if i am not mistaken i use a patch for a minor upgrade. And for a major upgrade i can just use the actual installer.

[Daniel]

Hello,

Thanks for the reply dan.

But it still doesnt work, if the source msi isn't there, i can not patch it

I've edited (using AI 11.4.1) your sample and attached it here. Can you please download and test it and let me know if the patch installation succeed when launching with the following command line?

Code: Select all

msiexec.exe /p "<path_to_patch>Patchproject.msp" /qb REINSTALLMODE="omus" REINSTALL="ALL"

If the patch installation still fails, please try to iterate a step by step test case which we can follow.

test.zip

(936.13 KiB) Downloaded 553 times

And yes i am aware of the windows ignoring the last version number. But if i am not mistaken i use a patch for a minor upgrade. And for a major upgrade i can just use the actual installer.

I'm afraid I don't fully understand this. The main difference between a patch and a major upgrade is that a patch contains only a diff between two MSIs so it have a smaller size (than a stand alone installer) and a major upgrade compatible setup is a stand alone installation package (which is of a bigger size than a patch). However, in both cases, when building the setup installations you should take into consideartion only the first three fields of the "ProductVersion".

All the best,
Daniel

[vidur]

Hi daniel,

thanks for your reply. It worked. May I know what you changed to get it to work?

I'm afraid I don't fully understand this. The main difference between a patch and a major upgrade is that a patch contains only a diff between two MSIs so it have a smaller size (than a stand alone installer) and a major upgrade compatible setup is a stand alone installation package (which is of a bigger size than a patch). However, in both cases, when building the setup installations you should take into consideartion only the first three fields of the "ProductVersion".

What i meant was, When I change the last 3 digits of the version, on my side i consider it as a major upgrade. And i use the 4th value for patching. I.e: i use a patch for small changes from 1.0.0.0 to 1.0.0.1 and when i make a big change i make it a major upgrade 1.0.1.0
Is that allowed?

[Daniel]

Hello,

thanks for your reply. It worked. May I know what you changed to get it to work?

The only significant change I did was to set the ProductVersion to correct versions (i.e. "1.0.1" and "1.0.2").

What i meant was, When I change the last 3 digits of the version, on my side i consider it as a major upgrade. And i use the 4th value for patching. I.e: i use a patch for small changes from 1.0.0.0 to 1.0.0.1 and when i make a big change i make it a major upgrade 1.0.1.0
Is that allowed?

Please keep in mind this is not correct. No matter how you want to build your installer package (as a major upgrade or as a patch), you should make sure you change one of the first three fields of the "ProductVersion", otherwise you will build packages with the same versions as Windows Installer ignores the fourth field of the "ProductVersion". Usually, when a patch is built you should change only the third field and for a major upgrade you should change the first or the second field instead.

All the best,
Daniel

[wyzerd]

Hi Daniel,

The most important part is that the 4th set is "Build Number" and has no effect on the process of patching, 1.00.00.0 is no different from 1.00.00.999999999999 as far as windows installer is concerned.

The third set is designated as Maintenance number. This is the set that would indicate a Patch. Windows Installer does under stand this.

Upgrades are controlled by the first 2 sets. The first set is MAJOR Upgrade and the 2nd is MINOR upgrade. I believe it is generally accepted that and seldom exersized that the only time the Major number is supposed to be upgraded is when the preceding product is not compatible with the previous product version. In theory any correctly versioned number of a software with the same major number should be able to work with any system where that major number is equal regardless of the Minor number.

My advise to the user experiencing pain with this is to implement change and educate the organization of the designed functionality these number play in configuration. Continuing to misuse the numbers will cause inconsistent results in the installed customer base.

Best of luck.

G