5 replies to this topic

[SrikanthCJ]

All,

We are creating patches which are cumulative. In order to avoide a large number of patches listing in Add / Remove programs, we thought we will create supercede patches. Hence, when ever we create a supercede patch we increment the sequence number and create a patch.

Observatioin:
Only the latest patch will be listed in the Add / Remove programs. If we remove the latest patch, the previous patch is displayed. For example, if patch 01 and patch 02 is applied on a product. Only patch 02 is displayed. When we remove patch 02, the display shows patch 01.

I want to know if the above method is correct.?

If any body can explain or point me some resource to understand the internal of patch removal, it will be of great help.

Any comments are appreciated.

regards,
Srikanth

[akerl]

The patching process is very complex. When you apply a patch the msi is registering the patch for the product. In every installation process like maintenance, repair, reinstall, patching windows installer loads the cached installation in memory and applied all registred patches (excluded superseded and obsoleted patches) to get the final view of installation. Ifa patch is superseded it is registred for the product but not active in the installation view, so information in this patch are not applied to the installation product. In your case, you're working with supsedencing only, you've n patches on the system but only one active patch. This is the patch that is shown in ARP. If your remove the patch, the older patches change state from supersede to active and was included in final installation view. You can see the behavior in installation loag when your start logging with /l*vx. ARP shows only active patches.
There is a german book from Microsoft Press "Windows Installer 3.1", which described the patching process in depth.

[SrikanthCJ]

Thanks very much for the information.
I am eager to see the english version of the book. Hope it will be releasing soon.

I have one more question. If you can answer it will be a great help.

Below is the scenario.

Subject "Shared File reverting back to older version when the patch is removed from one of the affected products"


We have a file that is shared by more than one Product.(Say CAC1033.dll delivered by both the products in the same folder and it is a shared file).
Now we created a new version of CAC1033.dll and created a uninstallable patch for each of the product. We were able to see the patch listed in the Add / Remove programs for each of the products.

If i remove the patch lets say from Product1, we observed that CAC1033.dll is reverting to the base version of the product. In this case, even product2 lists patch in the Add / Remove programs, where as the file is the older version. This is causing Inconsistency.

We would like to know how do we avoid the files reverting back in the above scenario.

Any help is appreciated.

[akerl]

Yes the scenario is correct. The primary goal in a removing patch solution is the functionality of the own application. If you have shared files, there is a big problem, because MSI remove the patch and go to the state before the patch was applied. MSI doesn't look if a file is shared by another application. In this scenario you must make a repair of the other application. Sorry, there's no other way.

I've written the book only in german language, but I hope Microsoft Press will translate them to english.

- Andreas

[SrikanthCJ]

Appreciate your reply.

I think this is a serious problem and there is no concrete solution for this as this may occurs in various scenarios.

I tested your suggestion of repairing the other application. I think we repair the application, it reverts back to the base version.

I applied the patch again and used repair mode, then it restored to correct version.

Do you have any idea of invoking repair mode of a installed application with out using the base msi.( I am assuming that the base application msi will be cached).?

thanks,
Srikanth

[akerl]

You can call msiexec /fomus <product code>. In this case msi will look into the cache and use the package, but when a ressource is missing, msi must access the original installation package, because ressources are extracted from the cached package. I think that in your case msi mustn't access the original installation package because the ressources are saved in the patch unistall cache.

- Andreas