Windows Installer-Avoid FileinUse dialog box when Installing a package - wix

When ever there is an update patch of files that have to be replaced with the existing files and if one of the files is being used by any of the processes, then a file in use dialog box pops-up.I wanna avoid that dialog box and get that file queued up for installation so that it can be installed at the time of system reboot.
I have read that the queuing the files for update at the time of reboot is the inbuilt functionality of windows installer.
Can someone suggest me the way to remove that FileInUse Dialog box.
I tried setting up the "MsiRMFilesInUse" property to "0" but it didn't work.


"Short" Answer
Essentially: you could 1) run completely silently (suppresses the files-in-use dialog), 2) shut down locking
applications gracefully (application update to allow graceful shutdown - with or without restart manager support), 3) ensure proper service control (if dealing with services), 4) force-kill
running processes (the "sledgehammer-approach"), 5) abort setup if locks are detected, 6) require logoff before deployment, 7) install to a new folder for each version (side-by-side install), etc...
Below is a little drill-down of files-in-use issues and the Restart Manager - intended as a quick review for files-in-use and reboot issues.
In terms of your actual problem. I wouldn't mess with the FileInUse dialog(s). It won't really solve your problem. Maybe consider these pointers:
Services: If you are installing services and they trigger files-in-use issues, please see section on services towards the bottom to determine if you can improve your setup's logic.
Silent Mode: Running your setup in silent mode would be an obvious way to suppress such files-in-use dialogs, but then you have to suppress automatic reboot, or the system will spontaneously reboot without warning. Details below.
Policy: Please check if the DisableAutomaticApplicationShutdown policy is enabled on your box / standard PC configuration. See details below.
Registry location is: HKLM\Software\Policies\Microsoft\Windows\Installer.
I am not sure if enabling this policy will make the files-in-use dialogs disappear.
Restart Manager Compliance: Maybe check if you should update your application to heed the design of the Restart Manager feature - to allow for auto-magic and problem free upgrades by applications shutting themselves down gracefully (provided you are dealing with binaries that you can actually change yourself - in other words: you have the source code). Lots of details below.
"Setup Overkill": If you deem it safe to kill your application without mercy during upgrades, see section on this below.
Graceful Shutdown Custom Action: If you make your application capable of graceful shutdown (restart manager-style), then you can trigger such a shutdown yourself as well (easiest for user context processes) via an immediate mode custom action (in case Restart Manager is disabled by policy - look out for timing and timeout issues though - especially for silent running - "deadlock").
Side-By-Side Installation: some details below. Some companies decide to install applications truly side-by-side so there are no file overwrite issues with their new deployments (old versions uninstall may still trigger required reboots though).
I suppose you could also abort the install if locked files are detected, or you could require users to log off before the installation is run - if you have a distribution system.
Please at least skim the rest of the answer for more details and context.
Restart Manager
Your applications and services should be prepared to be shut down by the Restart Manager and save user data and state information that are needed for a clean restart. This requires updates and changes to the application / service to adhere to standards for shutdown and restart of the application.
The Restart Manager: is a new C-style API available beginning with Windows Vista and Windows Server 2008. Restart Manager consists of a single DLL that applications can load to access the Restart Manager API. The idea is that the Restart Manager will auto-magically shut down and restart your applications during installations / updates, by having the application / service follow a set of guidelines:
Guidelines for Applications - (the crucial tech-read)
Guidelines for Services
In essence: The whole idea is basically to prefer restarting applications rather than restarting the OS - and also to avoid reboots in general.. To that end: 1)
Your application calls RegisterApplicationRestart() with a command
line specified for its eventual restart - it "signs up" for restart
management. 2) Your application watches for WM_QUERYENDSESSION
messages and shuts down gracefully saving data in an appropriate way
when told to do so. 3) Then Restart Manager can restart the
application when finished installing (restart can be disabled).
More Technical stuff:
Here is a nice Symantec article on "Files In Use & The Restart Manager".
How do I add support for Windows Restart Manager to my application? (Advanced Installer)
Restart Manager Configuration: There are a number of properties that will affect how the Restart Manager will operate with Windows Installer:
MSIRESTARTMANAGERCONTROL - use the Restart Manager or FileInUse Dialog
MSIDISABLERMRESTART - restart or don't restart shut down applications
MSIRMSHUTDOWN - shutdown, force shutdown or do not force shutdown
When Restart Manager is used, the MsiRMFilesInUse dialog is used instead of the FileInUse dialog to show a list of applications that have locked files.
N.B! The whole Restart Manager feature can also be disabled by policy:
DisableAutomaticApplicationShutdown policy.
Check in HKLM\Software\Policies\Microsoft\Windows\Installer.
Restart Manager behavior with Windows installer
FileInUse
If you don't have the time or resources to implement proper interoperability with the Restart Manager (which is frankly the only sane thing to spend your resources on at this point in Windows's development), then there are a few things that might be good to know:
Silent Install: The first obvious thing to point out is that there will be no FileInUse dialog if you install the setup in silent mode. However, this could trigger a system reboot unless you specify the REBOOT=ReallySuppress property.
Services: Do you install services that you do not properly shut down during upgrade? There are built-in MSI constructs to shut down services during upgrades - the Service Control table.
Used properly, this ServiceControl feature means you no longer have any problems with service executables triggering a reboot to be replaced (barring shutdown problems in the service itself).
This is a built-in MSI constructs and works well when used right. People should not resort to custom actions to install services.
Application Support: Beyond interoperability with the Restart Manager, some application - that have files in use - can shut down gracefully when told to do so.
Some applications shut down properly when sent a command line, for example App.exe -shutdown, despite not having been written to be interoperable with the Restart Manager. Maybe system tray applications that save no data for the user?
This obviously has to be implemented specifically for the application in question - and if you do that, you should use the Restart Manager instead at this point (or additionally, you could have both call the same actual shutdown implementation).
"Setup Overkill": some setups are designed to just kill application processes that are open at the time of installation.
Not ideal, but it can work for certain types of applications that run in the background (OK, it is nuts, but it is done regularly).
Use a custom action or whatever built-in constructs are available in your deployment tool.
WiX: Kill windows service forcefully in WIX. WiX: CloseApplication.
VBScript: Close an application using VBScript.
Advanced Installer: How to detect or stop a process.
Installshield: Kill process. Kill process documentation.
REINSTALLMODE: Do you perhaps use REINSTALLMODE="amus" to force overwrite files during installation?
This can dramatically increase the amount of files in-use and reboot prompts since all files are attempted replaced - and generally unnecessarily so - especially in repair and modify scenarios.
This is particularly true for setups that install services that do not use the ServiceControl table properly to shut down the service before trying to overwrite its binary.
Side-By-Side Installations (SO): adding this for reference, it is beyond the scope of what is "normally relevant". This approach requires quite a bit of technical changes and proper distribution processes to be successful - it is primarily for in-house, core corporate applications (full app control possible) - in my opinion.
New versions, targeting new installation folders (add version number to installation folder?), can generally install without any file overwrite issues (unless any system-shared files are updated - in which case you should split them to a separate pre-requisite MSI - with its own distribution logic - when required - which should be rarely).
Older version uninstall can still trigger reboot requirements as the files can be in-use and not ready to be uninstalled. Obviously.
You can use automatic GUIDs for the setup components - so MSI can keep them tracked separately in a correct fashion. You must generally eliminate all need to set static components (or they must be installed to shared locations and kept static - or updated via a separate pre-requisite MSI when required).
The whole application must be "well behaved" for side-by-side use and installation. In other words not fight over file associations and load all resources properly and manage database connections that could be shared between instances, etc...
You add the version number to the start menu shortcut? Somehow you must be able to differentiate installations and launch the desired version - obviously. The application should be aware of its doppelgängers?
I might consider setting a new upgrade code for each release, in order to decouple the products from one another, and then use the distribution system to uninstall older, legacy versions (as a weekend or monthly batch job?). This is not 100% necessary, it all depends on your scenario. Lots of things can work when planned coherently - obviously.
Applications not suitable for normal side-by-side operation may sometimes be virtualized and sandboxed using App-V (virtual packages) to allow different versions to co-exist on the same box. New challenges.
Some Further Links:
FileInUse or FilesInUse (lots of inside information from a Symantec employee towards bottom)
Terminating process in CustomAction
Restart Manager behavior with Windows installer
How can I stop an .exe on repair, update and delete in wix?
RmGetList() API fails when file is locked using Ez file locker but works with another file locking utility
Suppress an MSI error code
Wix stop service on uninstall/upgrade: prevent "restart popup" (file-in-use situation)


Assuming you are the package author, I would suggest following the norms, which are to use the MsiRMFilesInUse dialog. But if you want to attempt to disable things anyway, start by understanding the guidance for package authors on Using Windows Installer with Restart Manager:
Add the MsiRMFilesInUse dialog box to your package. If the MsiRMFilesInUse dialog box is present in the package, the Windows Vista user running an installation at the Full UI user interface level is given the option to automatically close and restart applications. An installation package can contain information for both the MsiRMFilesInUse dialog box and the FilesInUse dialog box. The MsiRMFilesInUse dialog box is only displayed if the package is installed with at least Windows Installer 4.0 on Windows Vista, and is otherwise ignored. Existing packages that do not have the MsiRMFilesInUse dialog box continue to function using the FilesInUse dialog box. A customization transform can be used to add an MsiRMFilesInUse dialog box to existing packages.
End-users typically run installations at the Full UI user interface level. Basic UI or Reduced UI level installations give the user the option of using the Restart Manager to reduce system restarts even if the MsiRMFilesInUse dialog box is not present. Silent UI level installations always shut down applications and services, and on Windows Vista, always use Restart Manager.
: : :
Package authors can base a condition in the LaunchCondition table on the MsiSystemRebootPending property to prevent the installation of their package when a system restart is pending.
Package authors and administrators can control the interaction of the Windows Installer and Restart Manager by using the MSIRESTARTMANAGERCONTROL, MSIDISABLERMRESTART, MSIRMSHUTDOWN properties and the DisableAutomaticApplicationShutdown policy.
Setting MSIRESTARTMANAGERCONTROL=Disable, possibly removing the FilesInUse and MsiRMFilesInUse dialogs from your package, and optionally tweaking further settings discussed on System Reboots (such as setting the REBOOT or REBOOTPROMPT properties) may have the effect you desire.
If you are not the package author, you are probably asking in the wrong forum. The
DisableAutomaticApplicationShutdown policy sounds like it could do most of what you describe, and would apply to all packages installed on your machine. It is intended for use by systems administrators instead of package authors. Alternately you could create transforms (or specify properties on the installation command line) to effectively alter the package like the package author would have.


Hopefully not repeating too much here, but I'll start by pointing out that the reason for that dialog is to avoid reboots. You didn't say why you want to wait for a reboot instead of using the in-use functionality that lets you avoid rebooting in the first place. It's also unclear about when your next reboot is expected, the issue being that the install of the app is not complete until all the files have been completely replaced and updated. It's not unusual for an incompletely installed app to crash because its current state is some set of old and new files mixed together.
There is no MsiRMFilesInUse property, so setting it has no effect.
The MSIRESTARTMANAGERCONTROL property tells Windows whether to use the older FilesInUse behavior or the new Restart Manager FilesInUse methods of in-use detection. It does not turn off files-in-use behavior detection, it's just a switch between old and new methods. Because the detection methods differ you may see different behavior depending on what files are actually in use (only apps with open windows are detected by the old methods).
You should say which tool you are using to build your MSI file because they have different capabilities. Visual Studio setups have virtually no support for automatic shutdown, except that if you are installing services with installer classes then your Uninstall method could be extended to stop the service at uninstall time. If you are using WiX then there are util::CloseApplication capabilities.
The supported Windows shutdown method is to integrate your apps with Restart Manager, and Stein has links. For services, the "normal" service install with MSI ServiceInstall/ServiceControl takes care of this, but not for Visual Studio setup projects with installer classes.
Finally, create an MSI verbose log and look for in use entries, usually with a 1603 error (the file in use flavor, not the install crashed flavor). You may not need this log if the dialogs tell you the apps that need shutting down, so just focus on a way to get them stopped on an update, because that's a better solution rather than attempting to suppress the default Windows behavior.

Related

MSI Installer revert the modified installation files if application starts with other user

I have a scenario,
On a particular machine, I am installing my custom software with MSI installer. MSI installer is created with PerMachine tag, so software is available for all the users of that machine.
Now,
I installed the software on C:\MyApp\ directory.
Then I modified a few configuration files present in C:\MyApp\Config folder to make sure the software connects with my other services.
I started the application, it's working fine.
Now, on the same machine, I logged in with another user.
I started the application.
MSI windows popup with some progress bar for installation.
It vanishes and the application starts but fails to load.
But all the files I have modified are reverted now, I need to again modify those.
Few points:
My installation direcotry is C:\MyApp, not any custom user directory. So modified files should be for all the users.
I think MSI is rolling back changes when I logged in with the new user.
How to stop this?
Please help

Self-Repair: Windows Installer self-repair is the cause of the behavior you see. See the link for an explanation of what happens. See more here - several links with information on self-repair from various angles.
Short Explanation: Essentially the launching of an advertised shortcut triggers an integrity check of the installed files and if a file or registry setting is found to be missing a self-repair ensues. It will put in place missing files and settings. During this process it will sometimes overwrite changed settings files - the problem you describe (due to various file overwrite oddities of Windows Installer - a long answer with various hints).
Fix?: My preferred fix for this is to not install the settings files and update them, but to rather have your application generate them on first launch - either one file per user or a shared one for all users. You can also use a read-only copy of the settings file that you install to copy to a new file that you generate and update. I also recommend you put these files in a writable location in the user profile and not in the main folder. Your setup will never interfere with these generated files. You can also try to set the hosting component for the files "permanent" and "never overwrite". Not very neat. Here is a whole rant on the subject. The very best solution - in my opinion - is to keep settings in databases and get them on launch. This allows good control of all settings. Look out for network and firewall issues.
I hope this answers your question. Are you installing IIS files? I find commercial tool Advanced Installer to have the better feature list for IIS installation - though I lack enough data to conclude. Some videos here: https://www.youtube.com/c/advancedinstaller/search?query=IIS - WiX is also very good, but without the nice GUI of Advanced Installer.
Note: you really should not install to the root of C:\ anything at all. Windows Installer actively tries to make it hard, and side-effects are likely. You can, however, target the IIS folders - wherever they are located.
Update: I found this old answer on how to allow selective update of settings files - I had to resurrect the linked forum answers from Wayback.

Any side effect for chocolatey if software updates by itself and one tries to update through choco again?

Some programs installed by Chocolatey have the feature to self-update. Examples are VS code and PyCharm. Will there be any side effects if one uses choco to upgrade the software after the software has done the self-update?
I am using Windows 10, python 3.8, anaconda distribution.

If by "side effects" you mean try to download when they shouldn't, or download and revert to outdated files that they shouldn't, the answer is no. They don't just retrieve the packages, they manage them.
handling dependencies during installs and upgrades is the main purpose for package mgrs. to exist. They manage stuff like that so developers do not need to. Otherwise, building any type of project with current methods and standards would be extremely challenging so you don't have to.
Chocolatey, like most package mgrs., runs a 2 step process as a result of the upgrade command. First it checks for newer versions, If there are none, it does nothing. The convention for nearly all automatic upgrade processes is the same. Because of this, either one only retrieves when it needs to.
Companies like IntelliJ and Microsoft usually have relatively robust Deployment schemes, regardless of the method. If a package manager was going to break (or breaking) their automatic update, they would either fix the compatability issue or choose to forgoo the install method. So long as you verify your sources before downloading anything from anywhere, you should be ok.

Side Effects
Side effects should not be present, as it depends on whether the application also successfully overwrites the files, which should be the case.
If PyCharm executes the self-update and the Chocolatey package manager updates the PyCharm application at the same time, errors may occur and the files may not be overwritten successfully.
1. Solution — Deactivate Self-Update
You can manually disable the self-update option integrated in the application.
If the application does not allow you to disable the self-update option, try disabling the update service via the Services application.
2. Solution - Deactivate the Update Service via Services
The Services application allows you to make configurations of the services developed by the respective application.
It is strongly recommended that you create a restore point before making any changes to services.
If you make a mistake that cripples your computer, you can use the restore point to perform a system restore and undo the changes.
If you have disabled the wrong service and lost access to the computer, try booting into safe mode to change the service back.
Configure the update service via the Services application and set the status to Disabled.
Example: Deactivating the Brave Update Service

How can I force reboot after installation completion? Burn/bootstrapper in WiX

I have created a bundle using WIX.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Name="ClientSoft" Version="1.0.0.0" Manufacturer="Tests" UpgradeCode="GUID">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<MsiPackage SourceFile="file1.msi" Visible="yes"/>
<MsiPackage SourceFile="file2.msi" Visible="yes"/>
</Chain>
</Bundle>
</Wix>
I am installing only MSI files. The bundle will be executed with -silent option.
I would like to force a restart(without prompting) after bundle installation completion.
Adding -forcereboot does not help.
How can I force a reboot after all MSI files are installed?
EDIT:
'regular user' will not use the system, therefore I do not consider restarting out of blue as undesired behaviour - restarting out of blue is exactly what I need.

Burn Reboot Notification: As far as I know Burn will show a reboot prompt after installation if any of the embedded MSI files schedule a reboot (that can be done by scheduling the standard actions ScheduleReboot or ForceReboot - and Windows Installer will schedule a reboot by itself if a file can not be replaced during installation).
I believe the Burn bundle will handle suppressing the reboot until the installation is done - by virtue of the command line they use to invoke each MSI, but I am not 100% sure. There could be special concerns for ForceReboot. Just use ScheduleReboot, and condition it well - as explained here.
Moreover the whole bundle seems to refuse to uninstall if a reboot is pending. Not sure what happens when the bundle runs in silent mode, it seemed to kick off a failed reboot. Haven't tested too thoroughly.
Pending some testing. Need to do something else first.
Rant: I wrote a whole reboot-rant, just for you below :-). The gist of it: just do not reboot unexpectedly or spontaneously.
Unfortunately Windows Installer itself will spontaneously reboot when
run in silent mode, unless you specify REBOOT=ReallySuppress on
the command line - if a reboot is indeed pending.
Don't: Causing a spontaneous, unannounced reboot is actually technically easy (custom action, or an MSI run in silent mode that sets ForceReboot - or even ScheduleReboot without setting REBOOT=ReallySuppress on the command line - described here - in detail - or you can hard-code the REBOOT property to "Force" in the property table - this will also trigger a reboot without warning). Rebooting like this is logically and pragmatically unsound. Extremely so in fact.
Ethics for Rebooting: Rebooting a knowledge worker's PC is very serious, I have seen people sent out the door for less. This is nothing to be nonchalant about: Dozens of Visual Studio windows, heaps of half-written emails, notes in notepad, and the plague itself: missed chat messages and web pages without state management, etc... Beyond losing data (which still happens, though most apps save before closing), people lose context (obvious, but still) - it is as if someone took your physical desktop and swiped it clean with documents ending up on the floor and in the trash can (now politically correctly referred to as the "recycle bin").
There is more:
What if you reboot and there are many users logged on?
Someone could be careless enough to install on a server that needs careful management of reboots (for example: multiple servers need to be booted in a specific order for auditing and various purposes - yes, it happens and the air will be full of not so good words).
God forbid you reboot a terminal server out of the blue with the whole company logged on (not even sure it is possible).
The list could be made very technical - the strangest things happen. System administrators could for example make a batch file for "semi-automatic installation". In other words they kick of the batch file - it runs the MSI in silent mode with a few prepared settings and the box reboots without warning. Not sure what features have appeared in Windows to deal with this on server OSs.
What if you force an immediate and spontaneous reboot via a custom action and the MSI is one of many being run in sequence in a Burn bundle? Not sure what Burn does to handle this? It might have features to handle it.
The bottom line is this: your software could be thrown out of whole
companies for "behavior" such as this. Haphazard rebooting. It really can. As in "...if they do this, what else do they do that we can't live with".
Civilized Reboot: I am not sure of all the aspects here, but I would recommended something like this for software that can not work without a reboot:
Premonition: Announce before the installation starts that a reboot REALLY
is necessary after installation. Allow early exit. Helps everyone.
ReallySuppress: Do not ever disrespect an MSI file's command line set to REBOOT=ReallySuppress in order to suppress all reboots (this is a built in feature of msiexec.exe - Windows Installer engine - you can suppress all reboots scheduled by an MSI, theoretically - there are still hacks).
We need this working in the business and to eliminate the freebasing approach of doing whatever whenever in terms of rebooting.
The poor system administrators who have to deal with freebasing packages resort to desperate measures to prevent spontaneous reboots: Is there a really-really-really-don't-reboot parameter for msiexec?
Admins really go to these extremes to prevent reboots (removing system privileges for reboot to control what is going on). I don't recommend they do this since this can cause other, unexpected problems - technical hacks always do. Always side-effects. The right approach is to eliminate reboot hacking in packages. Isn't it? Or an update to Windows that really suppresses unexpected stuff like this.
Standard Approach: After installation Windows Installer itself will show a dialog to reboot. Allow this standard approach to be used. And as stated: respect reboot suppression for a silent install. Note that Windows Installer will show a reboot dialog - if files need to be replaced - even if you did not add an explicit ScheduleReboot command in your MSI file. Automagic.
No Soup For You: You can make your application refuse to launch before a reboot is done. Many ways to do so, maybe just scan for a file that needs to be replaced for example before you allow to launch. Opens up for potential launch bugs, so keep it simple. The EXE might not even get off the ground if there are necessary prerequisites requiring a reboot. I wish we could hide shortcuts added until reboot is complete (if reboot is really, really needed). Or a modal dialog that can't be dismissed without kicking off reboot? Loaded gun that. I prefer to not add any buttons to kick off a reboot in the application, I just state a reboot is needed and exit - if this is indeed necessary. Less to test for the QA guys?

Use /forcerestart instead. It's the Standard Installer Command-Line Options that Burn follows.

What do I do when launching an application triggers repeating, endless Windows Installer self-repair?

Windows Installer self-repair can cause problems for both developers, system administrators and end users. Finding the solution can be difficult if you have limited MSI experience.
This is a Q&A-style answer intended as a check list for solving self-repair problems. Here are a few common problem scenarios:
Repeated Windows Installer self-repair might occur whenever you launch an application on your workstation. How can this be fixed, or how can components be disabled so it never occurs again?
A WiX installer may be deployed and you see repeated Windows installer self-repair whenever you try to launch the application.
When enabling or installing an MS Office addin, you experience continuous Windows Installer self-repair on application launch of one or more MS Office applications.
When working on legacy solutions in VB6 or VBA, self-repair kicks in for an unrelated product when you launch the main developer IDE.
When opening a form in Outlook, Excel or Word or similar applications, self-repair kicks off for an unrelated product from another vendor.
Keywords: Windows Installer launches unexpectedly. MSI displays unexpectedly. Windows Installer appears every time. Opening Application Starts Windows Installer. Windows Installer self healing. How does a package self-heal. MSI self-heal best practice. Windows Installer repair. Self-Repair. Disable Windows Installer. Windows Installer repeatedly runs. Application Shortcut launches installer instead. Windows Installer appears unexpectedly.

Self-Repair, Simple & Short Explanation: Why does the MSI installer reconfigure if I delete a file?
Concrete Design Advice for your WiX / MSI File
I keep trying to write about repeating MSI self-repair for developers, but end up with too much detail. Here is my last attempt: concrete design advice for what not to do in your WiX / MSI file.
The answer below provides a checklist for solving any self-repair scenarios - from any vendor or source, not just your own. Check the answer linked above for your own MSI package design concerns.
The "Short Version" - Self-Repair Checklist
To permanently and reliably fix self-repair problems for everyone, developers and setup developers must be involved since the real fix must happen at the vendor level.
If you are in a corporate environment, poor-quality application re-packaging can also cause self-repair problems, and you should involve your application packagers to determine if the problem is from the vendor or not.
System administrators must know what they are looking at, and when no fix is available, use various workarounds to deal with the problem in the wild. Even end users can try some easy workarounds themselves (see section 5).
The essence of self-repair problems:
Most self-repair issues are COM-related, and there are two general fixes for vendors and developers: 1) use the properly deployed, shared COM libraries generally deployed via merge modules, or 2) use registration-less COM to "shield" your application from self-repair and compatibility issues.
Your setup developer can implement the merge module fix, developers must test. Merge modules are standardized, shared deployment libraries for shared files.
Registration-less COM only works with developer involvement in my experience. This option is particularly relevant if the developer needs to use a particular version of a COM file (for whatever reason). Details in section 5.4 below.
Apart from COM, you can also cause self-repair problems by having your setup developer register file- and MIME-associations and command verbs in your MSI setup. Use sparingly, and ensure your file-/MIME associations are unique.
Finally you can cause self-repair by any file- or registry conflict between two installed MSI files. They "share a resource by mistake" and will treat it as its own - battling it out until the conflict is resolved.
Some self-repair problems are not caused by errors in the vendor application or setup at all, but by external factors in the computer environment in question, such as interference from tinkering users, scripts, viruses, anti-viruses or security software. See section 3 for more details.
Quick Options For Dealing With Problem Applications
Perhaps jump straight to section 5 for the list of suggested fixes and workarounds if you are sure the self-repair you see is caused by MSI alone (and not by other, external causes as described in the first few sections below).
Most of these proposed "solutions" in section 5 are really mostly system administrator tricks that don't fix the underlying problem - as stated above the real fix has to come from the vendor. The exception is "5.4: registration-less COM", which can actually help developers "shield" their applications from self-repair problems.
If you don't have admin rights on your box you are advised to try "solutions" 5.2, 5.3 or 5.1 (5.1 will generally require admin rights to try, but it is non-complicated). These are "quick workarounds", the others are more involved. If these workarounds don't work, please ask your admin to read the other suggestions.
Understanding Windows Installer Self-Repair
I have written at length about this issue before, but it focused too much on understanding the problem rather than actually finding an acceptable fix for it. You can read the full explanation of self-repair problems here: How can I determine what causes repeated Windows Installer self-repair?.
Fixing Windows Installer Self-Repair Issues
To actually fix repeated and endless self-repair, you can try the suggestions below in section 5 - in increasing order of complexity and difficulty. Before doing so, you should verify what the real source of the self-repair problem really is. It might not be caused by MSI files, but by other, external causes (such as scripts or users deleting files or anti-virus blocking files).
If the problem is indeed MSI-related, you can try to disable advertised shortcuts and COM addins, use registration-less COM, get help from the application vendor, uninstall offending applications, virtualize packages or full on hack the cached MSI database and registry (not recommended, and only really possible with expert help). It all depends on your scenario. If external causes such as scripts are at fault, you must eliminate this interference. See details below - just follow the check-list.
The first steps for problem solving are to identify that the problem really exists in the wild on your platform, and then to determine what application(s) trigger the self-repair in the first place:
1. Verify that the problem really exists in your environment.
It is generally always possible to figure out what is going on to cause the problematic self-repair, and there are several viable workarounds that can be utilized to deal with the problem. It is, however, not always possible to find a good, permanent fix (without vendor help - as described below).
Accordingly, if you are a system administrator trying to find a fix for your self-repair issue, perhaps make sure the problem is seen on more than one computer - especially if the problem is seen on a developer-, QA- or even a test computer.
If you only see self-repair problems on one computer, an alternative might be to rebuild the problem computer. Effectively eliminating rather than "solving" the problem. There is a relatively high risk that you might see the problem again though. If you ask me, don't rebuild, it is no solution - but what tends to be done in the real world I guess.
Be aware that an AD-advertised MSI install that is slow to install and keeps getting aborted by users can "look like" a self-repair issue for desktop support, but this is expected MSI behavior. Allow the install to complete once (it is possible to change the installer progress bar to disable the cancel button - something like msiexec.exe /I "MyApp.msi" /QB-! for progress bar only with no cancel button and no modal dialog at the end).
2. Identify the culprit(s) for the self-repair.
It is possible for a single application to cause the problem on its own, but typically there are at least two applications that conflict (they share some resource by mistake).
The trigger for the self-repair is generally possible to find in your event viewer on the system where the self-repair took place. Follow these steps to open the event viewer:
Right click "My Computer"
Click Manage
Click continue if you get an UAC prompt
Go to the Event Viewer section, and check the Windows Logs
Identify the offending application in the Windows Event Log by looking in the "Application section" of the event log and you should find warnings from the event source "MsiInstaller" with IDs 1001 and 1004.
You can find a lot more details on how to do this in the more elaborate answer here: How can I determine what causes repeated Windows Installer self-repair?. Look in the "Finding the trigger or culprit for the self-repair" section.
You can also try the advice from independent deployment specialist, MSI-expert and MVP Stefan Krüger. He has an article about the same self-repair issue. And he crucially discusses the actual event log entries and what they mean. Please read about the actual debugging procedure there.
3. Verify that external non-MSI causes are not causing the problem
Anything that deletes files or registry settings, manually or automatically, can trigger MSI self-repair. Especially if you are messing around deleting stuff in the user profile or in the HKCU section of the registry.
In most cases such triggers will only cause a single self-repair to run and then the problem is fixed (this is how self-repair is supposed to work and help users). Allow self-repair to run once and then launch the application again to test if the problem is gone. It should be, and your application should launch correctly from now on.
Special case: Ironically you can sometimes fix a broken application by renaming its HKCU application key (in the user section of the registry) to actually force self-repair to run and install the application's default data in the user profile - if that data was accidentally deleted (this type of fix generally does not work on terminal servers).
If the same file or registry entry is deleted again by automated means and self-repair results, you must eliminate or update the automatic process that is causing it and your problem is solved and you can stop reading. If you manually deleted the file again yourself, then you may suffer from bad memory :-).
In summary cleanup scripts, logon scripts, cleanup applications or tinkering, overactive users can all cause this kind of self-repair.
Finally viruses and also anti-virus software (and other security software) can block access to files and trigger self-repair that will never succeed.
For an infected computer, just rebuild the computer. It will save you time overall.
For anti-virus / security software problems, bring out your security guys to solve it. They may need to contact the vendor in some cases (particularly for false positives).
Whether virus or anti-virus related, check the offending file on http://www.virustotal.com to verify whether it is actually a virus or just a false positive (which can be an even bigger problem for self-repair).
Personally I have seen several anti-virus / security software related self-repair problems, but no real virus-related problems (so far). I guess viruses normally infect core system files rather than application files, and core system files are not to be deployed by MSI files (shared system files might be included in MSI files, but not core system files).
4. Contact the vendor(s) (or your own packaging department).
Once you have verified that the self-repair problem is MSI-based and it is not your own software, the first thing to try is to contact the application vendor(s) and see if they have an updated installer to eliminate the problem.
It is important to try this option since all other options are "workarounds" and not real fixes. The problem can only be completely resolved permanently by changes in the vendor installer and possibly the application executable itself.
Fix 1: The fix can be as simple as having the vendor remove privately installed but globally registered COM files with the appropriate, shared "merge module" to install the run-time correctly for everyone. These should install COM files properly to shared locations where they can be globally registered without side effect. Ready for everyone's use.
Fix 2: If the vendor claims this isn't possible - then they should be able to provide a proper registration-less COM installation with properly isolated COM files installed to the main application folder. They should also take care of deploying any security updates whenever they would come along.
Important!: If the vendor either uses the correct, shared merge module to deploy files or provides an isolated installation using registration-less COM, then the problem should be solved permanently for everyone.
The problem can also be caused by other issues, but very often COM is the culprit. Sometimes a cleanup of their MSI installer can resolve other, more obscure conflicts. If you know a good application packager, he/she should be able to quickly identify conflicts (and provide feedback for the vendor).
Note that it is also possible that the self-repair is caused by erroneous (in-house) repackaging of vendor software. In that case you can fix your own packages via updates delivered by your own packaging / deployment department (and they should definitely be able to achieve this for most cases). This is in fact a very common issue.
5. Select a "workaround" or fix to deal with the conflict situation.
If the vendor(s) won't provide a fixed installer package, you need to find a "workaround" to deal with the situation. There are several options, and some "quick workarounds" should be tried before you delve into too much complexity. Here are some problem solving suggestions in order of increasing levels of difficulty and complexity:
5.1: Just uninstall the culprit(s).
The absolute simplest fix is to figure out what application(s) trigger(s) the self-repair and just uninstall it, if that is an acceptable solution for your environment (it rarely is).
This can be acceptable if there are two (or more) applications in conflict and one of them is rarely used or "optional".
You can run the problem application on a virtual machine instead (see section 5.5). This would be my preferred "fix" for a very "misbehaving" application. All problems should disappear without any real debugging (which is costly).
Plain uninstall is an option that is at least worth considering - some software can be very problematic in more ways than one, and should simply be rejected for use. Be sure to let the vendor know that the software was rejected as well. It might be the only way to make them take the problem seriously.
5.2: Remove Advertised Shortcuts.
The first Windows Installer workaround to try is to remove "advertised shortcuts" (essentially a special type of shortcut that points to an Windows Installer application feature, and not directly to an executable or file). Read the linked article from Symantec for details on advertised shortcuts.
Note that shortcuts can be created "anywhere" including in special folders such as the "Startup" folder. This particular location means a self-repair can be triggered by itself on system startup (without user interaction).
Use an MSI viewer tool and open the system-cached MSI and inspect its Shortcut table to find all shortcuts. In order to find a list of all cached packages you can try this answer: How can I find the product GUID of an installed MSI setup? (open the package path specified in "LocalPackage").
You then re-create a regular shortcut that points directly to the executable in question. This will "bypass" the most common trigger of self-repair (the advertised shortcut). In some cases this avoids the whole self-repair issue. It is worth a try.
Be aware that even if this appears to work straight away, self-repair might still re-appear whilst you work inside the application (for example when you open a particular form). You need to "pilot" this fix with some users who actually use the application actively to make sure it is a good enough workaround for your environment.
You have also merely eliminated the symptom of the problem, the registry or file conflict that caused it has merely been "bypassed" or "silenced" - it still exists, but this may be good enough if the applications exhibit no problems during operation.
There is in fact a way to disable all advertised shortcuts on installation of any MSI package. You set the property DISABLEADVTSHORTCUTS (in one of the ways described in the link), and then all shortcuts will be created as regular shortcuts and they will not trigger self-repair. There are at least two problems:
1) The package could be designed to use self-repair to install userprofile files or HKCU settings. In this case this data will then never be added to the system as intended since self-repair will never run, and the install is effectively incomplete.
2) There is no guarantee that self-repair won't still occur - since it can be triggered by other advertised entry points such as COM invocation, file and MIME associations and command verbs.
5.3: Disable COM addins (if possible).
If your problem is related to the loading of an add-in (for Outlook, Excel, Word or other apps like AutoCAD or similar), then there are no shortcuts to tweak - the addin is loaded on launch of its "host application".
The easiest to try is to disable any addins you don't need in the addins dialog of the application in question (often Outlook, Excel or Word or similar) and see if this makes the problem go away. In some cases you are just disabling COM addins that users never used in the first place, and the problem has been eliminated.
And, rather obviously, also try to disable addins that you actually need as well, in order to check if the problem can be related to its loading. If the addin is the culprit, you should continue down the check list to the next proposed solutions (next bullet points).
I should re-iterate that the preferred solution would be a fix from the vendor (most often it would involve making the addin properly use the latest, shared ActiveX/OCX controls in question - other addins could still trigger the problem though, if they are also badly designed. You could end up dealing with multiple vendors - usually blaming each other).
In fairness to the vendors, the problem can also be caused by bad corporate application repackaging - if you are on a corporate machine. Then you must deal with the packaging department for a fix.
5.4: Try registration-less COM
Arguably this solution is more complicated than virtualization (which is described in the next bullet point), but I put it here since it might be a preferred option for some people.
Registration-less COM is something I have rarely used, but it is said to be a viable solution: Generate manifest files for registration-free COM. This essentially bypasses the registry and activates private copies of the COM files controlled by manifest file(s) placed next to the application executable(s) - effectively shielding the application from COM registry interference (in theory). "Everything happens in the same folder".
Your in-house packaging department might be able to use this to deal with "difficult vendor packages" to "isolate" their problems. However, I am not convinced registration-less COM will work properly without a few additional application tweaks contributed by the original solution developer, but I lack the empirical data to back it up. If it is an in-house app with source available, give it a test spin (and let us know).
My main problem with this approach, is that it opens up potential security holes (private copies of COM files that will never be patched by Microsoft), if you don't make sure the isolated components are updated yourself. Updates would likely cause lots of manifest-rewrite work as well (but are these old COM files updated at all anymore anyway?)
Note that registration-less COM, at least in theory, can be used for all COM related conflicts, whether they are VB6 executables, VC++ applications that use COM, etc... I am honestly not sure if it works properly for (office) COM addins (dlls) and VBA forms.
Here is what appears to be one of the better MSDN articles on registration-less COM): https://msdn.microsoft.com/en-us/library/ms973913.aspx (there is even a downloadable MSI with the samples - which ironically seems to trigger an error for me on launch).
Personally I would probably rather try a virtual package using APP-V rather than trying to use registration-less COM (see next bullet point).
It should be re-iterated that rather than "shielding" your own application - the correct vendor fix is to stop deploying private copies of shared COM files that are erroneously registered system-wide, and start installing them as intended using the appropriate merge module for deployment.
5.5: Virtualization (APP-V, Virtual Machine, etc...).
Apart from uninstalling or disabling components, the simplest fix is arguably to use virtualization to "isolate" the applications that conflict. If you still want the applications on your main SOE (Standard Operating Environment), you could try to use a virtual deployment package (APP-V). This is an application that is basically installed on demand (on launch) and runs "sandboxed" or isolated from other applications on the system.
You can also use a virtual machine via systems such as VMWare or Microsoft Virtual PC to run the problematic application(s) in their own operating system. Often people have admin rights when using virtual machines, but don't on their main SOE system (main workstation). Many developer applications are more effective to use with admin rights, so this solution might be particularly useful when dealing with development teams and their requirements.
5.6: Windows Installer tweaking - (Experts only!).
If the problem is very serious for your desktop environment and none of the options above work, you can try to fix the problem at a Windows Installer level. It might be worth it if the addin (or whatever other software) is crucial to have available on the company's main PC environment.
Essentially what you need to do is remove offending entries from the system cached MSI and/or the registry (disable advertised entry points such as advertised shortcuts, COM registration, file associations, MIME associations or command verbs, etc...).
This is very involved and not good practice to do, and there are some side-effects (for uninstall, resiliency, etc...), but it is the only "last resort" that I know about.
In these cases you would be advised to contact a deployment / Windows Installer expert and have them analyze whether a "fix" is possible. It can work, but don't expect miracles.
If you insist on debugging yourself, you need to get hold of a tool to open cached MSI files on the system (such as Orca, Installshield, Advanced Installer or similar) and you need to "hack" the database - not recommended.
5.7: Windows Installer zapping - (Not safe!).
I am including this "option" for completeness and "historical purposes" if you like. It was never a good option, and is now very unsafe on newer versions of Windows.
MsiZap.exe was a Microsoft SDK tool meant as a last-resort tool for developers to clean out failed MSI installs or uninstalls, it was never intended for widespread use. It allowed the complete "dirty unregistration" of any MSI package. MsiZap.exe is now deprecated, unsupported and unsafe to use. Use only on throwaway virtuals, if at all.
Back in the day a common "system administrator trick" was to use MsiZap.exe to "zap" a whole Windows Installer package from the system. Besides leaving your system incurably dirty, it also removed all self-repair problems for that application.
The junk that is left behind after running MsiZap.exe includes essentially everything (except the actual MSI database registration). All files, all registry entries (including COM), SharedDll ref counters (which really screw up things on reinstall), services, anything really. You will never be able to uninstall properly. In most cases you will fail to install upgraded versions of the same application without side effects. Many people actually see more self-repair problems afterwards when trying to install on top of the dirty state.
Rob Mensching, creator of WiX, Orca and all things Windows Installer has a blog post on the perils of MsiZap. MSDN describes another bad side effect: All program update information is removed when you use the Msizap.exe tool to uninstall a program from a Windows-based computer
6. Summary & conclusion
Step 4 - contacting the vendor for a fix - is the only "real fix" in my opinion.
All other proposals try to deal with the problems that result from vendor errors, rather than provide a lasting solution.
The real-world problem is that many vendors tend to blame each other, so you might be out of luck. And some vendors who do it right, do suffer from the design errors of others.
Proposals 5.1, 5.2, 5.3 are non-complicated "workarounds".
Should be safe to try for everyone.
Proposals 5.2 and 5.3 should be possible to try even without admin rights.
Proposal 5.4 - registration-less COM - is a rather involved, potential "fix".
Developer involvement might be required to find all dependent files to "isolate".
In my experience this is the kind of project that ends up taking days to try out (even with expert help) - without a real guarantee that it will eventually work.
I hear conflicting things from experts, some have succeeded, some say it fails. The people with access to the solution source seem to succeed.
Personally i don't like it for the potential security holes it opens up, and any new file versions to deploy could mean a new round of manifest re-authoring (I believe).
However the COM files in question are so old now that it is rather unlikely that they will see any security updates made to them anyway. I suppose these COM objects are mostly used for .NET interop nowadays.
Proposal 5.5 - virtualization - is a common option these days and should probably be tried before 5.4 if available in the environment. As the saying goes, "virtualize, seriously".
I honestly don't know (lack experience) if virtualization is viable for (office) addins. Please update if you can confirm.
Executables can definitely be virtualized.
Proposal 5.6 - "cached MSI tweaking" - is a "hack" that can work "good enough" when done right by deployment specialists.
There are some "side effects", particularly for uninstall - and also for "resiliency", but these should be manageable if done right.
It is the "real world" - nothing is "clean".
And proposal 5.7 - "zapping MSI" - is an unsafe, deprecated "legacy hack".
There are several side effects due to the system's "dirty state".
Total corruption of the MSI database has been reported after running MsiZap.exe.

There must be problem inside your package.
To find issue.
Clear eventlog - application.
Run your application as user with AdminRigths
Application should run after self-repair. You can run twice, if self repair will not appear,after when you run second time, it's meant that there is problem with component that want to create entry inside MachinePart like HKLM or Programfiles or Windows folder.
Open your eventlog and look for entry with source MSIInstaller.
Entry with warning will give you information what feature and component will cause self repair.
If you can show us here log from that warinig we can tell you more about your problem, but in general message inside eventviewer is clear and says what resource is missing.

Since it happens every time you launch your app (and I assume that you allow the repair to run to completion) the most likely cause is that the app removes something that is "protected" by Windows Installer, such a registry entry or a file. The shortcut initiates the repair mechanism to reinstall the missing item, and the MsiInstaller entry will tell you what it is.
In general, repairs are a good thing because they allow the user to repair the installed product if it's damaged. If, by design, there are resources that are installed but not required to be repaired then set the Component Id to null in your WiX, because that is the documented way to prevent repair of certain files, see ComponentId remarks here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).aspx

Adding software setup to installer

I'm writing an installer for an application. Most of the installer is done and working, but I have on more step outstanding. I need some way to add a setup window to the installer, that will take user input like server address and port, etc. and write these to the relevant files for system start-up. This preferably done through a GUI of sorts inside the installer.
I've tried creating an executable file that runs after installation, but this does not always execute on different systems.
Is there a way to add a GUI to the installer itself that executes after the directory structures and files have been put into place?
Thanks in advance.

In general you should seriously consider doing this as a standalone app that runs when the app first runs and needs configuring. Then it's a program that runs in a user context and can be tested and debugged in the normal way. At least consider what the user is going to do if they want to change the server address or the port - will they need to uninstall your app and reinstall it just to change the server details or the port?
The GUI may not run correctly when started from the install for a number of reasons. It may be initiated with the system account if it's a deferred CA. It wasn't started from the interactive user shell, so it probably won't have any idea of a working directory. It's being run from an msiexec.exe process running in the system directory and maybe with a system account - that's not really the place to be doing your GUI configuration.

I assume you're using WiX, it doesn't say so in your question but it's tagged with WiX.
I would have a read of http://wix.tramontana.co.hu/tutorial/user-interface-revisited (or http://www.dizzymonkeydesign.com/blog/misc/adding-and-customizing-dlgs-in-wix-3/ has a relatively easy to read example), you can add or edit any of the dialogue boxes in the installer, you'll need to download the source to get at the built in dialog, and it does require some "play" to get everything quite right but worth it to get a professional looking installer.