Problems using Patch

[Quadiago]

Hi there people

I made a patch package using Advanced Installer, and I'm having trouble getting it to apply correctly. When I run the .msp file, I get the "Welcome To Setup" dialog, which is fine. Then, the next screen that shows is "Select Installation Folder" which obviously isn't right. Then it shows you the "Ready to Install" dialog. A funny things happens now: If you click Install, it shows "Welcome To Patch Setup". From there you can continue to install, it does something, finishes happily, but nothing happens to the installed application.

What might be going on? This has got me completely confused. When I choose the patch in Orca to see the changes, everything appears to be fine.

[Cosmin]

Hi,

Please make sure that you created the patch by using the steps explained in this tutorial:
http://www.advancedinstaller.com/user-g ... patch.html

If this is the case and the problem can be reproduced on other computers then please send us a small test case that reproduces this behavior to support at advanced installer dot com so we can investigate the problem.

Regards,
Cosmin

[Quadiago]

Hi cosmin

I identified the problem as the consequence of changing the product code between the target and updated packages. I'm assuming you specifically don't support patches where the product code changes? I noted during testing that this is mentioned when you get prompted to change the product code.

If that is the case, wouldn't it be prudent to have "Allow product code mismathes" in the patch project to be unchecked by default and perhaps additionally warn the user about this issue if he does check it?

If you do make this mistake the behaviour during application of the patch is rather bizzare and I never got the idea I was doing something wrong.

Thanks,

[Cosmin]

Hi,

I'm assuming you specifically don't support patches where the product code changes?

Please note that one of the rules of creating Windows Installer patches is to use MSI packages with the same product code. You can see a list of rules here:
http://www.advancedinstaller.com/user-g ... tches.html

If that is the case, wouldn't it be prudent to have "Allow product code mismathes" in the patch project to be unchecked by default and perhaps additionally warn the user about this issue if he does check it?

The "Allow product code mismatches" option is a feature that allows you to create a valid patch even if you use MSI packages with different product codes. Note that it is recommended that this option is checked when creating a patch. You can read more about the AllowProductCodeMismatches option here:
http://msdn2.microsoft.com/en-us/library/aa370890.aspx
http://msdn2.microsoft.com/en-us/library/aa368059.aspx

If you do make this mistake the behaviour during application of the patch is rather bizzare and I never got the idea I was doing something wrong.

It is possible that the behavior you encountered was not caused by the product code mismatch. Note that usually, with this option checked, you should be able to create a valid patch when the MSI packages have different product codes.

Regards,
Cosmin

[Quadiago]

Hi again

I spent a little time to create a very basic example to test whether it is in fact possible to make a working patch when the product code has changed.

This is what I did:
I created a new project in AI v6.0.1 and left everything to defaults except for adding a text file to be installed. In the file (readme.txt), I wrote "Text file v1". Then I built the install, and copied the .msi to a subfolder. I subsequently changed the text file to say "Text file v1.0.1" and "Text file v1.0.2" and changing the product version to match and kept the resulting MSIs. For v1.0.1 I kept the product code and in v1.0.2 I let AI generate a new one.

I then went and made two patch projects, the one to update v1 to v1.0.1, and the other from v1.0.1 to v1.0.2. I left all the options to defaults.

The first patch works and the second, unfortunately, doesn't (the same behavior is found as described earlier).

Should I send you these files?

Regards,

[Cosmin]

Hi,

I have managed to reproduce the behavior you encountered.
This is what happens:
- you create two MSI packages with different Product Codes that will be used to create a patch
- you install the first one
- since the second MSI doesn't have the same product code as the first, the patch installation doesn't see where the first product was installed, therefore it shows you the dialogs needed to get this information (the dialogs of the second MSI)
- once the information is gathered, the patch dialogs are shown (right after the dialogs of the second MSI)

This behavior is encountered because of the different Product Codes. I recommend that you create a patch that meets the patch rules:
http://www.advancedinstaller.com/user-g ... tches.html

Note that this kind of patch does work, you simply need to make sure that you provide the correct path (the path of the first installation) for the second MSI.

Regards,
Cosmin

[Quadiago]

I understand what you are saying, but I believe that it should be possible for both types of patches (with or without product code changes) to behave in the same way.

Since the patch knows exactly what products (i.e. product codes) it should update, it must be able to find the existing installation correctly. Otherwise it would be impossible to do silent updates without custom actions that interrogate the system.

Note that the component rules that apply are all met by the simple test scenario.

Then, lastly: even when I do specify the exact folder (I actually just keep the default) I used for the initial install, the patch with the changed product code doesn't work. It appears to do nothing at all.

I realise that it should, but it simply doesn't.

Thanks for the help so far.

[Cosmin]

Hi,

Note that this is normal Windows Installer behavior and it cannot be controlled. Also, this happens when you create a patch that breaks one of the rules of creating patches.

Otherwise it would be impossible to do silent updates without custom actions that interrogate the system.

Please make sure that the patch respects the patch rules and you do not generate a new Product Code after increasing the version for the updated package.

Then, lastly: even when I do specify the exact folder (I actually just keep the default) I used for the initial install, the patch with the changed product code doesn't work. It appears to do nothing at all.

Please send a test case reproducing this behavior (the AIP files, resource files and resulted MSI and MSP files) to support at advancedinstaller dot com so we can investigate this problem.

Regards,
Cosmin

[Quadiago]

Note that this kind of patch does work, you simply need to make sure that you provide the correct path (the path of the first installation) for the second MSI.

What I was trying to say is that I couldn't get this to work as you said it should.

I'll send you the files that I tested with in email.

Regards,

[Quadiago]

Note that this is normal Windows Installer behavior and it cannot be controlled. Also, this happens when you create a patch that breaks one of the rules of creating patches.

In fact, this statement isn't accurate. Normally, .MSPs don't "run" as .MSIs do. The reason why running the .msp works is because of the custom action you added. In other words, I suspect this issue to be linked to that custom action.

[Cosmin]

Hi,

I have studied the test case you sent and I cannot find out why you are encountering this behavior. Please note that a major upgrade (changing the product code) will not always work and it is not recommended for patches.

In other words, I suspect this issue to be linked to that custom action.

This issue is related to the Windows Installer behavior when a patch performs a major upgrade. Please create you patch project without changing the Product Code for the upgraded MSI.

Regards,
Cosmin

[Quadiago]

Fair enough, I'll just take care to not change the product code when I intend to use patching.

It is interesting though that WI allows you to change it in a patch, but seemingly there isn't much point in allowing it.

By the way, I found the reason why the UI was being screwy. To make it handle ...

*time passed*

*somewhat later*
I've interrupted myself here because I couldn't believe that it should be impossible to use a patch for a major upgrade.

I digged around in the MSI in Orca and ran some logs during the application of the patch to try and figure out why the install with the patch was doing nothing.

Before this, I discovered that the reason the UI sequence was messed up was because the condition on the "WelcomeDlg" entry in the InstallUISequence was not sufficient: it didn't cater for the situation where "Installed" was FALSE and "PATCH" was TRUE - so I changed it to:

Code: Select all

WelcomeDlg	(NOT Installed) AND (NOT PATCH)	1230

This only solved the weird UI though. Some more digging in the logs revealed that the installer was attempting to reinstall a product that wasn't installed in the first place (because of the new product code).

This led me to the ControlEvent table, where I changed the "Next"-control's condition so that it doesn't set "ReinstallMode" and "Reinstall" if the application isn't installed:

Code: Select all

PatchWelcomeDlg	Next	Reinstall		All	AI_PATCH AND Installed	3
PatchWelcomeDlg	Next	ReinstallMode	ecmus	AI_PATCH AND Installed	1

So what happens now is that the "Welcome To Patch" UI still shows during a "major patch", but it actually does a major upgrade. I.e. it worked!

Yey

Don't worry, I won't ship anything like this, but this shows that it should work and what you'd need to change to make it work out-of-the-box.

Sorry for being so hard on this, it just had me a bit frustrated.