Difference Between Self Heal and Repair

Self Heal and Repair are two different concepts in Windows Installer which people many times consider to be the same thing, however there is difference in these two.

Self Heal is triggered by advertised shortcuts, or other advertising information in the package which eventually Repairs the application.

When the application is launched by advertised shortcut, it checks for all the key paths of the Current Feature, if any of the key paths is missing it will launch Repair.

Note that if there are multiple features then it will not check the missing key paths of the other features, but only the feature of which the advertised shortcut is launched.

Repair of an MSI can be triggered by

Repair button in Add/Remove programs
Giving the command line msiexec /f{other option} {MSI name}
Self Heal by advertised shortcut or other advertising information.
Active setup
Once the repair of the package is triggered, even with Self Heal, then the whole of the MSI is reinstalled. Then it does not see that only the feature which triggered the self heal should be repaired, but the whole MSI, by which I mean, all its features are reinstalled.

Hope this clarifies the difference between two.

How REINSTALLMODE=amus Works

In any of these installation transactions, viz. initial installation, repair, reinstallation, on-demand installation or patching an MSI, The REINSTALLMODE has an affect on it.

Here is what "amus" means:

* a - Force all files to be reinstalled, regardless of version
* m - Rewrite all registry keys that go to HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT
* u - Rewrite all registry keys that go to HKEY_CURRENT_USER or HKEY_USERS
* s - Reinstall shortcuts and icons

The mentioning of "a" in amus forces the reinstallation of files on your machine irrespective of the file version rules. Every file updated by REINSTALL property will be updated in this case.

The sequence of events which happen actually depend on the authoring of your patch.

If your patch contains the full file, the installer will not access the source to reinstall that file, but if your file is the delta of the file, like an update to say ini file, then the patch will access first the machine file and update it, and if machine file is not accessible to the patch, then in that case, the installer will go and grab the file from the original source location and will work from there.

REINSTALLMODE=amus is not the recommended solution, but sometimes situations become inevitable and we need to use them.

Using SOURCEDIR Property in Package

SOURCEDIR property in MSI package refers to the location from where the MSI is installed in the machine. How do we use this property in our package.

If you want to use a file which is kept in the source folder (next to where your MSI is placed), through Custom Action then you need to follow this procedure.

The SOURCEDIR cannot be directly used in the package. If you read the logs then SOURCEDIR property is created and correctly pointed to the directory. But later the log shows that: Deleting SOURCEDIR... So the value of this property is deleted and the MSI does not get access to it. If you display message with [SOURCEDIR] property then it will be empty.

The work around for this is that we can put an Action in the sequence called: "ResolveSource" after CostFinalize action. Then if you place your Custom Action after this action which refers to SOURCEDIR property then you will get the correct value of SOURCEDIR.

Acknowledgement: I would like to thank my friend, Anurag, here who helped me to figure this out.... :)

Isolation of a File: Two Ways in One MSI

Generally you would have read that after isolation is done, we should not modify the MSI. So how to do .local and .manifest in the same MSI. Actually you would be thinking: "What is the need to do both types in the same MSI?" This is because, recently, I came across a situation in which we needed to do isolation of a file for installation of application in Windows 2000 through .local method and for installation in Windows XP and Vista through .manifest method. This was needed to be done through same MSI.

This is the solution. Create a .msi file with .local isolation method for windows 2000. Then create another .msi file with .manifest isolation. Note the visual difference of .manifest isolation file and the base MSI. Make all the differences seen in this to the .msi which was created with .local isolation. Then compile it. This will not get corrupted. Only the ones with .manifest isolation if recompiled again get corrupted. So take care of this and you can then conditionalize the components to be installed for 2000, XP or Vista...

How to Create Packages with a Size Greater Than 2 GB

Packages which need to include or which capture files with a total size exceeding 2 GB, it's necessary to use some tricks. Usually the MSI with cabs compressed outside the MSI allows the maximum size of cab files to be 2 GB. If the cab size file tries to exceed 2 GB, then the WISE package compilation throws an error.

For this you need to create separate features. In these separate features, distribute the files in the package so that the feature has a total file size of less than 2 GB.

After this you need to go to Media option in Installation expert and choose option one cab file per feature.

This will give you the MSI along with cab files which have size less than 2 GB.

Since the total package size will be very big, the downloading of cab files while deploying and then uncompressing them, will take lots of time. So the other solution is to choose the option of Uncompressed Files outside MSI in the media option. This will save time during installation.