Windows Installer is a deployment technology, its job is to install the specified files and registry settings and keep them in the specified install locations and to ensure they are the right versions – self-repair or resiliency is a mechanism to that end. Its operation conflicts with a developer’s need to exchange files on the fly for debugging, development and testing.
As a developer you may be interested in deploying your MSI and then deleting or replacing files on the fly to debug things. In these cases MSI can be a nuisance because it never stops doing its job and will reinstall the correct files. This is called “self-repair” and can be spectacularly annoying! :-).
There are a lot of ways to work around this, MSI is quite complex. Since the “self-repair” is normally invoked from an "advertised shortcut" the easiest way to avoid this MSI feature is to launch the EXE file directly from the file system and not via a shortcut. This bypasses the MSI self repair mechanism for all but the most complex EXE files. You can also manually create a non-advertised shortcut on the desktop that will not trigger a self-repair (right click and hold executable and whilst holding down the right mouse button, drag-and-drop to desktop and release button over an empty spot and click “Create shortcut here”).
For the record self-repair is triggered by “self-repair entry points” for key-path validation. They include advertised shortcuts, file associations, COM registry data among other things.
There is a lot more to self-repair, or resiliency which is its official name, please check this comprehensive article on self-repair problems to find ways to resolve your specific problem. It is a long article, but it should be worth the read if you have self-repair problems.
UPDATE, October 2018:
Self-Repair In Detail: More than anyone wants to know about self-repair:
- Self-repair – explained
- Self-repair – finding real-world solutions
- Self-repair – how to avoid it in your own package
Links: