New Post: How to guarantee custom actions aren't executed on upgrades

Hi José,

One obvious thing that can help is to fix the deployment to follow/respect "separation of concerns" principle.

Your config file does not belong to the deployment as is a part of the configuration. Remove the config file from your setup and update your application in such a way that it creates the config file with the defaults if it doesn't exist. This way you kill a few birds:

• You can easy reset the config file to defaults by simply deleting it.
• The config file can be auto-resurrected if it got deleted for whatever reason (e.g. by accident).
• Your config file will never be overwritten by setup as setup is not aware about it at all.
• The config file can be created in any location more appropriate than ProgramFiles (e.g. user profile).
• Your product can automatically handle advertised setup scenarios.
• Resetting/recreation of the config file doesn't longer require running setup in repair mode.
  

BTW, this principle "setup is only concerned about deploying files and the configuration is the responsibility of the application" is not something new. MS started enforcing this principle on the deployment solutions for the products to be officially "Windows certified" starting from introduction of Vista.

As for "UPGRADINGPRODUCTCODE" you are right MSI solution for that is messy. I can only suggest that you can play with upgrades and evaluate the properties as it is done in "Setup Events" sample. This way you may find some magic combination. Though if you follow my first suggestion you don't need to deal with detecting upgrades.