12 replies to this topic

[Superfreak3]

Hi all,

It's been a while since I posted here and I forgot what a valuable resource this site is and has been for me in the past.

Anyway, I have a question about the possibility of detecting if a patch has been applied. We have a client install that looks to a network share for updates. If there is an .msp file found in the share, it is executed silently. This way, if an old patch is there and no longer applicable to a current version they may have installed, there is no interruption to the user. We do recommend that the .msp be removed from share after complete deployment to all workstations.

However, we have this one user who doesn't know when all client machines will be updated. So, whenever our update utility is run, the patch keeps being applied. It's silent so no big deal, but this user indicates that an internal application setting is being reset with every run of the patch. I'm a bit unclear on what exactly is being changed, but that is beside the point for now.

Is there any way to detect that this particular patch has been applied and, if so, do nothing else? I could code something in our update utility if this is possible or is there a command line switch that accomplishes this?

Any help appreciated!

Thanks!

[Stefan Krueger]

Welcome back

Is this a minor update, i.e. did you increment the version number? In this case you should be able to target the patch only for lower versions.

[Superfreak3]

Unfortunately, the version did not change - Small Update.

[Stefan Krueger]

In this case, maybe patch sequencing would help.

[Superfreak3]

This is really a standalone patch and I'm getting errors when I try to apply the patch after creating it with Wise for Windows Installer.

I just used Patch Family = 100 and Sequence = 1. When I try to apply the patch I get....

No valid sequence could be found for this set of packages.

Even if I get it to apply successfully, is there something with sequencing that will prevent it from reapplying?

[Stefan Krueger]

Thinking of it again, I don't think it's possible to stop this patch from re-applying. Imagine a repair install - in this case the patch MUST be applied. You need to create your setup in a way that allows re-install/repair without resetting user data. Maybe you need to condition a custom action

[Superfreak3]

Yes, I have asked the reporter of the issue/situation to supply info regarding what exactly is being reset. From this, I hope to develope some type of workaround.

So when a patch is applied, do the CA's from the original package fire again? Is it actually triggering repair/modify install and placing the new files contained in the patch?

I did find some vbScript code to determine if a patch has been applied or not.

Edited by Superfreak3, 29 April 2008 - 18:52.

[Superfreak3]

I guess I could use something like NOT PATCH so my Custom Actions will not run if a Patch is being applied. ??

From the SDK:

PATCH Property
The PATCH property is the full path of the current patch package.

The PATCH property is set by MsiApplyPatch or by using the /p Command Line Option. The PATCH property is set only during the first application of the patch. The patch is applied for each subsequent configuration of the product, but the PATCH property is not set.

Remarks
The PATCH property can be used in conditional expressions to control an action or user interface that is run only during the first application of the patch.

What does it mean by setting only during the first application of the Patch. In my instance does that mean the the CA's will run during the second, third application, etc. Or, is it only set once and held in cache somewhere?

If so, I'm hoping that even though my patch keeps reapplying, the CA's will not repeatedly run.

Am I on the right track?

Edited by Superfreak3, 09 June 2008 - 15:26.

[Stefan Krueger]

How will you handle reinstall? Maybe the proper condition would be
Not Installed
You might still get a problem with Major Upgrades.

[Superfreak3]

What do you mean by reinstall? That doesn't involve the PATCH property at all does it?

I guess I just don't want Custom Actions to run during patches that's all.

I'm sure down the road that this will present a problem in that I would need a certain CA to run. If the condition or a CA is changed in the updated release and a patch is then created, would this then allow the custom action, previously conditioned NOT Patch, to run?

[Stefan Krueger]

I don't understand why the custom action would be a problem during a patch but not during a reinstall/repair. These two actions are somewhat similar. Did you test a reinstall scenario (e.g. repair from control panel)?

[Superfreak3]

They probably are the same, but we typically don't use the repair option. If it is needed and application related 'stuff' gets reset by CA's, so be it in this instance.

However, our update utility runs on each login so some application specific settings are repeatedly reset by the re-application of the Small Update patch.

There has got to be a Windows Installer method to prevent this from happening.

I'll play around with the NOT PATCH conditioning.

[Superfreak3]

It seems that adding NOT PATCH to any CA that I do not wish to execute during a patch seems to do the trick.

I created a small install that calls notepad.exe at the end of the install. I then created a patch to this install and during its execution, notepad was fired.

Now, I added NOT PATCH to the CA's condition in the original .msi, cleaned my machine and reinstalled this altered .msi. Now, when I apply the patch, notepad is not executed.

I'm guessing its that simple!