Wix installer defaults to original Property value when another user logs in for the first time with app installed

Question

I have a Wix installer where I have a property defined (Product.wxs):

<Property Id="SITEBASE" Value="localhost"/>

<Component Id="ApplicationSettings">
    <File Id="ApplicationConfig" Name="MyApplication.exe.config" Source="$(var.Application.TargetPath).config"/>
    <util:XmlFile
      Id="ApplicatonConfig1"
      File="[INSTALLDIR]MyApplication.exe.config"
      Action="setValue"
      Value="[SITEBASE]"
      ElementPath="//MyApp.Properties.Settings/setting[\[]@name='SiteBase'[\]]/value"
      Permanent="yes"
      Sequence="1" />


<Component Id="ApplicationSettings">
    <File Id="ApplicationConfig" Name="MyApplication.exe.config" Source="$(var.Application.TargetPath).config"/>
    <util:XmlFile
      Id="ApplicatonConfig1"
      File="[INSTALLDIR]MyApplication.exe.config"
      Action="setValue"
      Value="[SITEBASE]"
      ElementPath="//MyApp.Properties.Settings/setting[\[]@name='SiteBase'[\]]/value"
      Permanent="yes"
      Sequence="1" />

My source MyApplication.exe.config has SiteBase = "http://localhost/AnotherValueForTesting"

I have a Dialog where I an set the value for SiteBase (starts off as the value from Property SITEBASE so will display: localhost

If I Install the application as TestUser1, changing localhost to 1.1.1.1 the config file has the entered value (1.1.1.1) and everything is fine. I can reboot and log in using TestUser1 and all is still good.

If I log in as TestUser2, the values for TestUser2 will now have "localhost" (the default for the property)

I can then uninstall, re-install (using the 1.1.1.1 value) and when I log in as TestUser1/2 both have 1.1.1.1.

If I then log in as TestUser3, TestUser3 again has localhost, not 1.1.1.1. I tested with a different value in the app.config to determine that the value is definitely defaulting to what is set for Property Id "SITEBASE" and not the original in app.config

PS: the Package InstallScope="perMachine"

Answer 1

Someone on our team found the problem. App logs had:

1. Detection of product '{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}', feature 'ProductFeature', component '{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}' failed. The resource 'HKEY_CURRENT_USER\Software\XXX\YYY\' does not exist.

2. Detection of product '{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}', feature 'ProductFeature' failed during request for component '{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}'

3. Beginning a Windows Installer transaction: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. Client Process Id: 19300.

4. Windows Installer reconfigured the product. Product Name: YYY. Product Version: 1.0.0. Product Language: 1033. Manufacturer: XXX. Reconfiguration success or error status: 0.

5. Product: YYY -- Configuration completed successfully.

6. Ending a Windows Installer transaction: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. Client Process Id: 19300.

installer creates a registry entry under HKCU. Because this is a per-user setting, it doesn't exist for the next user, so an MSI repair is begun.

Changing it to install to HKLM instead of HKCU looks to have fixed the problem

Answer 2

The short answer is that you're probably correct about the installer running again. It's a feature that if you have a file in a user profile directory (that therefore is installed at first only for that user) and then another user uses the app Windows will notice that the file is missing for that user and install it. Sine the application defines the file as being in a user folder it makes sense for all users to want that file also.

If that's not precisely what's happening, it may also be possible that the installed product is getting broken in some way and Windows is repairing it.

Either way, if you look in the Event log there should be MsiInstaller entries that refer to a missing component, quoting the guid that you can look for in your setup. That may help.