I must also warn that a lot of MSI files contain errors, sometimes serious ones, but trained application packagers will be able to detect this and in most cases eliminate the problem. I am adding this as a separate answer since it essentially answers a different question, but I feel it is relevant in the same thread.
The technical details involved in MSI are very complicated. At the basic level it is about decomposing your files and registry settings into components (atomic installation) and features (user selectable application parts to install, for example a dictionary feature). There are a number of best practice rule for splitting up the components, and errors in MSI files here are plentiful. These errors are generally handled by standardizing on the use of "major upgrades".
The actual installation is performed in a number of installation sequences, some with elevated rights. All of these things are defined in database tables, and this is where MSI is terribly complicated to understand and deal with. Spread throughout the installation sequences are standard and custom actions. The standard actions are Microsoft designed and need to take place (sequence can sometimes be modified). Custom actions are available to vendors to perform custom logic not covered by MSI itself. These can be in script or compiled form. Custom actions can be immediate (run at once, should not change the system but often does) or deferred (written into an excecution script that is then executed as a transaction and hence supporting rollback).
Typical errors in an MSI are (in no particular order):
- component creation errors (not following best practice). This can cause problems for patching and upgrades with mysterious symptoms such as missing files and settings or patches that bomb out with nonsensical errors.
- upgrade problems relating to user data being overwritten or reset
- incorrect scheduling of custom actions outside the "transacted section" of the installation sequences or custom actions of the wrong type are placed incorrectly. This often causes the actions to fail (no elevated rights) when run remotely via deployment systems and rollback is effectively crippled because only transacted actions are rolled back. The Windows Installer Transaction (think database transaction commit) runs between the standard actions InstallInitialize and InstallFinalize in the main installation sequence and runs with elevated rights. All changes to the system are to take place in this transaction - anything else is erroneous (but unfortunately quite common).
- use of immediate mode custom actions to make changes to the system outside the transacted install sequence. This breaks rollback support and will generally trigger security errors since immediate mode custom actions do not run with elevated user rights no matter where they are placed in the installation sequences.
- erroneous designs that cause repetitive cycles of self-repair to occur for no obvious reason.
- custom actions that do not obey the suppression of the GUI in unattended installation mode may show modal dialogs that causes deployment to fail completely
- the setup contains files that are not intended to be deployed in the location they are installing to. Typically system files that should be installed side-by-side in the winsxs assembly folder.
There are a number of more subtle errors and several larger, typical problems that I will have forgotten.