2

I have a WiX script that creates an installer that lays down an application in Microsoft Windows 7 and 10 machines silently. There are no options so there is no need for a GUI.

Some of the clients are complaining that when they launch the installed application (long after it was successfully installed), Windows pop-ups up the MSI installer message "Please wait while Windows configures [APPLICATION_NAME]". They say this happens every time and it runs for about as long as it originally took to install.

I used to get this a whole lot more and thought that it was because some of the installed files had been modified. I concluded that when the MSI ran the second and subsequent times it was overwriting the modified files with the original ones from the installer.

Since these files were intended to be modified after install, I added 'NeverOverwrite="yes"' to their Component definition as in:

<Component Id="..." NeverOverwrite="yes" Directory="..." Guid="...">

This seemed to solve the problem until now. Any ideas what I should be looking at or investigating further?

Garet Jax
  • 831
  • 1
  • 11
  • 22

1 Answers1

2

Short Answer: This is an MSI self-repair problem.

  1. Work out what component triggers the self-repair. Details below.
  2. Correct the situation by making changes to the setup eliminating the conflict situation.

Self-Repair: This is the classic "unexpected self-repair" issue often seen with MSI packages when certain conditions are met. I have written about this issue so many times that I will recycle some answers. I think the most accessible answers might be these two (please read at least the first link):

Debugging Using Event Log: To determine what MSI component triggered the self-repair you need to debug by inspecting the Event Log. This is described by Stefan Kruger's FAQ entry: Windows Installer launches unexpectedly, for no obvious reason. Alternatively read Flexera's Article: Understanding Windows Installer (MSI) Self-Repair (features nice screen shots).

Components & Products: When you have an offending component GUID, you can determine what product it belongs to by running this VBScript: Look Up Products for Component. It could be another product - if not just open your product's MSI file and find the component's key path.

Full Details: And the very in-depth answers with full explanations. Try the bolded third link for practical issues:

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

Other Resources:

Stein Åsmul
  • 34,628
  • 23
  • 78
  • 140
  • Thanks so much. I tried a number of searches, but couldn't come up with the "magic" terms to find useful results. This gives me reading to do in the next couple of days. – Garet Jax Dec 12 '18 at 03:12
  • Yes, it is a lot to read. Your problem might be simple. Just locate the component GUID in the event log, and then open your MSI to find the matching component. Then figure out what the key path is and take it from there. What type of application? What runtimes do you install? – Stein Åsmul Dec 12 '18 at 03:19