Why does the MSI installer reconfigure if I delete a file?

Question

I have created an MSI installer package in Visual Studio 2008. The problem is that after install, if I delete ANY of the installed files. This is not my intended behavior for my installer package. My File installation properties are:

PackageAs vsdpaDefault Permanent False ReadOnly False Register vsdrfDoNotRegister System False Transitive False Vital False

If this is trivial, please forgive me. I can't believe I have not been able to get Google to give up the answer. :)

Middlebrooks

Answer 1

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" (this excellent, little article has disappeared for me - perhaps it is still there if you log in) for key-path validation. They include advertised shortcuts, file extension associations, file MIME type association, COM verb activation (for example open), COM activation (registry) and direct call to Windows Installer and maybe even a few other things.

MSI Advertisement. In essence an advertised MSI installer is not installed, but registered on the system to be installed when invoked via "some mechanism" (the entry points above).

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:

1. Self-repair - explained
2. Self-repair - finding real-world solutions
3. Self-repair - how to avoid it in your own package

---

Links:

• Similar: Visual Studio 2015 msi build initiates another installation
• RestartManager causes worker role to restart
• What is the use of Repair option in a msi installer and what does it really do (internally)?
• Disable MSI auto-repair on installed program

Triggerhappy

Please note that there are a number of other ways to avoid triggering the repair. Most of these are not recommended, but using "non-advertised shortcuts" can be acceptable in some cases, for example when creating a version for the QA-team. With this kind of shortcut no self repair is triggered. For release versions I would enable advertised shortcuts since self repair is an important MSI feature. – Hom

Comprehensive explanation of self-repair – Hom

Answer 2

It's by design, known as "resiliency": http://www.msifaq.com/a/1037.htm.

Pomfret

Answer 3

I know I am late to the party on this, but I have found that adding 'NeverOverwrite="yes"' to the Component definition of the file(s) that are intended to be modified after the install, stops the self-repair from undoing my changes.

This has all but solved my self-repair issue. I added this to all configuration files and batch files within the MSI.

Sty

Yes, but don't do this to files you want updated like binaries or your setup will not update properly on upgrade - obviously. Better yet, make copies of settings files after installation and write to them leaving the original as an untouched "template". I am not sure if REINSTALLMODE=amus (force overwrite) would overwrite a key path set to "Never Overwrite". I remember testing it, but I don't remember what I found :-). That's what happens when you don't write it down. Thanks for sharing your tip! – Hom