WiX Installer Claims Success but takes no real action

Question

This is a follow-up to this question, same project- new symptoms.

I have used WiX Install tools in Visual Studio to create create an installer for my C# Windows Forms application. The plan is to have SCCM push the application out to our 50+ (Windows 10) workstations.

Currently this .msi is not working either manually executed or pushed by SCCM. The (non) results are identical regardless of method:

This installer does remove any previous version installed on the target system. It then claims to have installed the new version (1.1.1.1) and the new version appears on the Apps & Features list in Settings. References to the new version of the application are placed in the registry.

However none of the files are installed, none of the folders or shortcuts are created. Preexisting files, folders, and shortcuts are removed.

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product Id="82106de5-4591-4239-8356-a7cfa44fbc16" Name="PHSRP Dashboard" Language="1033" Version="1.1.1.1" Manufacturer="CSUS Public Health Survey Research Program" UpgradeCode="8420CB2B-6692-4BB9-A15A-023C7E69FB26">
    <Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" Platform="x64"/>

    <MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed."
                  AllowSameVersionUpgrades="yes"
                  IgnoreRemoveFailure="yes"
     />
    <MediaTemplate />
    <!-- UIRef Id="WixUI_Minimal"     Adds License dialog         -->
    <!-- UIRef Id="WixUI_Advanced"    Adds multiple dialog option popups  -->


    <Feature Id="MainProduct" Title="PHSRP Dashboard" Level="1" Absent="disallow">
      <ComponentGroupRef Id="ProductComponents" />
      <ComponentRef Id="CMP_StartMenu_Dashboard"/>
      <ComponentRef Id="CMP_DashboardAutoStart"/>
    </Feature>
  </Product>

  <Fragment>
    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFiles64Folder">
        <Directory Id="PHSRP" Name="PHSRP" />
      </Directory>

      <Directory Id="ProgramMenuFolder">
        <Directory Id="PHSRP_Menu" Name="PHSRP"/>
      </Directory>

      <Directory Id="StartupFolder"/>

    </Directory>
  </Fragment>

  <Fragment>
    <ComponentGroup Id="ProductComponents" Directory="PHSRP">

      <Component Id="CMP_Dashboard.EXE" Guid="939EC7DE-E6BD-4364-BFC7-7B03C03B7CBB">
        <File Id="FILE_Dashboard.EXE" Source="$(var.PHSRP_Dashboard.TargetDir)PHSRP_Dashboard.exe" KeyPath ="yes"/>
      </Component>

      <Component Id="CMP_DasboardConfig" Guid="4081EC5F-EAD0-4003-8B43-DFF1EF6B4348">
        <File Id="FILE_DashboardConfig" Source="$(var.PHSRP_Dashboard.TargetDir)\PHSRP_Dashboard.exe.config" KeyPath ="yes"/>
      </Component>

      <Component Id="CMP_EntityFramework" Guid="D685B056-E64C-4C9A-B0B0-C74DC5EF085E">
        <File Id="FILE_EntityFramework" Source="$(var.PHSRP_Dashboard.TargetDir)\EntityFramework.dll" KeyPath="yes"/>
      </Component>

      <Component Id="CMP_EntityFrameworkSqlServer" Guid="E017DCC8-1439-4CB6-BFDB-A8C86BF99D74">
        <File Id="FILE_EntityFrameworkSqlServer" Source="$(var.PHSRP_Dashboard.TargetDir)\EntityFramework.SqlServer.dll" KeyPath="yes"/>
      </Component>

      <Component Id="CMP_ReportViewerCommon" Guid="972220E8-5DD4-451D-847D-32DAC050D639">
        <File Id="FILE_ReportViewerCommon" Source="C:\WINDOWS\assembly\GAC_MSIL\Microsoft.ReportViewer.Common\12.0.0.0__89845dcd8080cc91\Microsoft.ReportViewer.Common.dll" KeyPath="yes"/>
      </Component>

      <Component Id="CMP_ReportViewerDataVisualization" Guid="B0AF7500-5743-4B48-85FA-9BA12E3B554A">
        <File Id="FILE_ReportViewerDataVisualization" Source="C:\WINDOWS\assembly\GAC_MSIL\Microsoft.ReportViewer.DataVisualization\12.0.0.0__89845dcd8080cc91\Microsoft.ReportViewer.DataVisualization.dll" KeyPath="yes"/>
      </Component>

      <Component Id="CMP_ReportViewerProcessingObjectModel" Guid="75E5E7AD-E1AF-41BC-BC95-464272966629">
        <File Id="FILE_ReportViewerProcessingObjectModel" Source="C:\WINDOWS\assembly\GAC_MSIL\Microsoft.ReportViewer.ProcessingObjectModel\12.0.0.0__89845dcd8080cc91\Microsoft.ReportViewer.ProcessingObjectModel.dll" KeyPath="yes"/>
      </Component>

      <Component Id="CMP_ReportViewerWinForms" Guid="831D08B1-047B-46E0-AA89-C1D47B0B4EBE">
        <File Id="FILE_ReportViewerWinForms" Source="C:\Program Files (x86)\Microsoft Visual Studio 14.0\ReportViewer\Microsoft.ReportViewer.WinForms.dll" KeyPath="yes"/>
      </Component>

      <Component Id="CMP_SQLServerTypes" Guid="EE385FEE-A4C9-4F9A-800E-F2B9C573DCA7">
        <File Id="FILE_SQLServerTypes" Source="C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SqlServer.Types\12.0.0.0__89845dcd8080cc91\Microsoft.SqlServer.Types.dll" KeyPath="yes"/>
      </Component>

      <Component Id="CMP_SystemNetHttp" Guid="F56581DD-D9D0-4140-BB66-9DEF7FF66D7B">
        <File Id="FILE_SystemNetHttp" Source="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Net.Http.dll" KeyPath="yes"/>
      </Component>
    </ComponentGroup>

    <DirectoryRef Id="PHSRP_Menu">
      <Component Id="CMP_StartMenu_Dashboard" Guid="B8C6D5CE-26BD-45E1-904D-97FC3EEADAE8">
        <Shortcut Id="SCUT_RunDashboard" Name="PHSRP Dashboard" Description="Start Dashboard" 
                  Target="[#FILE_Dashboard.EXE]"
                  WorkingDirectory="PHSRP" />

        <RemoveFolder Id="UI_RemoveShortcut" Directory="PHSRP_Menu" On="uninstall"/>
        <RegistryKey Root="HKCU" Key="Software\PHSRP\PHSRP_Dashboard">
          <RegistryValue Name="sm_shortcut" Type="integer" Value="1" KeyPath="yes"/>
        </RegistryKey>
      </Component>
    </DirectoryRef>

    <DirectoryRef Id="StartupFolder">
      <Component Id="CMP_DashboardAutoStart" Guid="E10E004B-8A38-43F9-8365-4C44267565F2">
        <Shortcut Id="SCUT_DashboardAutoStart" Name="PHSRP Dashboard" Description="AutoStart Dashboard"
                  Target="[#FILE_Dashboard.EXE]"
                  WorkingDirectory="PHSRP" />

        <RegistryKey Root="HKCU" Key="Software\PHSRP\PHSRP_Dashboard">
          <RegistryValue Name="su_shortcut" Type="integer" Value="1" KeyPath="yes"/>
        </RegistryKey>
      </Component>
    </DirectoryRef>

  </Fragment>
</Wix>

The install log is too large to include in this post and I am not familiar enough with the process to know what lines I can delete, so it is posted on my Google drive.

It indicates a successful install:

    MSI (s) (DC:40) [18:34:09:378]: Note: 1: 1728 
    MSI (s) (DC:40) [18:34:09:378]: Note: 1: 2205 2:  3: Error 
    MSI (s) (DC:40) [18:34:09:378]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1728 
    MSI (s) (DC:40) [18:34:09:378]: Note: 1: 2205 2:  3: Error 
    MSI (s) (DC:40) [18:34:09:378]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 
    MSI (s) (DC:40) [18:34:09:378]: Product: PHSRP Dashboard -- Configuration completed successfully.

    MSI (s) (DC:40) [18:34:09:378]: Windows Installer reconfigured the product. Product Name: PHSRP Dashboard. Product Version: 1.1.1.1. Product Language: 1033. Manufacturer: CSUS Public Health Survey Research Program. Reconfiguration 

success or error status: 0.

The strangest thing I see is that all the component "Requests" have been set to Null, which I understand means "do nothing". Why?

MSI (s) (DC:40) [18:34:09:300]: PROPERTY CHANGE: Deleting MsiRestartManagerSessionKey property. Its current value is '954c47bc279c3944a8f5054677c82967'.
MSI (s) (DC:40) [18:34:09:300]: Note: 1: 2205 2:  3: Dialog 
MSI (s) (DC:40) [18:34:09:300]: Feature: MainProduct; Installed: Advertise;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:300]: Component: CMP_Dashboard.EXE; Installed: Absent;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:300]: Component: CMP_DasboardConfig; Installed: Absent;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:300]: Component: CMP_EntityFramework; Installed: Absent;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:300]: Component: CMP_EntityFrameworkSqlServer; Installed: Absent;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:300]: Component: CMP_ReportViewerCommon; Installed: Absent;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:300]: Component: CMP_ReportViewerDataVisualization; Installed: Absent;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:300]: Component: CMP_ReportViewerProcessingObjectModel; Installed: Absent;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:315]: Component: CMP_ReportViewerWinForms; Installed: Absent;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:315]: Component: CMP_SQLServerTypes; Installed: Absent;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:315]: Component: CMP_SystemNetHttp; Installed: Absent;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:315]: Component: CMP_StartMenu_Dashboard; Installed: Absent;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:315]: Component: CMP_DashboardAutoStart; Installed: Absent;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:315]: Component: __CMP_StartMenu_Dashboard65; Installed: Null;   Request: Null;   Action: Null
MSI (s) (DC:40) [18:34:09:315]: Component: __CMP_DashboardAutoStart65; Installed: Null;   Request: Null;   Action: Null

Here is another weirdness- The log says it is not going to remove existing products (Skipping RemoveExistingProducts) but it does remove the existing version:

MSI (s) (DC:40) [18:34:09:331]: Doing action: RemoveExistingProducts
MSI (s) (DC:40) [18:34:09:331]: Note: 1: 2205 2:  3: ActionText 
Action ended 18:34:09: InstallValidate. Return value 1.
MSI (s) (DC:40) [18:34:09:331]: Skipping RemoveExistingProducts action: current configuration is maintenance mode or an uninstall
Action start 18:34:09: RemoveExistingProducts.
MSI (s) (DC:40) [18:34:09:331]: Doing action: InstallInitialize
MSI (s) (DC:40) [18:34:09:331]: Note: 1: 2205 2:  3: ActionText 
Action ended 18:34:09: RemoveExistingProducts. Return value 0.

Why is it referring to this install as "maintenance mode or uninstall"?

Update:

I ran the install on a freshly imaged machine. The installation completed normally, all the files and shortcuts are present, but for some reason the application simply does not run. Double-clicking on the PHSRP_Dashboard.exe file produces no error message. The Application log Shows a .NET error then an Application error. I don't know if this has to do with my application, the new computer's network connection, or the installer. I'm done for today though, back at it tomorrow.

Meanwhile the new install log is online.

Update 2:

The problem on the fresh workstation was a configuration issue. The installer is working as expected- at least when run manually. I need to try SCCM again.

The final piece to this puzzle is repairing whatever damage was done to the machines I was using for the SCCM Test. I can reimage them but would prefer to avoid that. Any suggestions would be welcome.

No time to look at this, but just want to check if you have tried on a clean virtual as of yet? If not, please do so. You could be in a inconsistent installation state (database is partially corrupted). Also, try configuring your package to use early uninstall for the MajorUpgrade. This involves making sure RemoveExistingProducts is early in the InstallExecuteSequence. Something like: Schedule="afterInstallInitialize" added to the MajorUpgrade element I think. — Stein Åsmul, Jul 16 '19 at 00:41
Can you also add a verbose log with extra debug info (`msiexec /l*vx`)? This adds the "client state" to the component log info. Windows Installer puts your MainProduct feature into "advertise" mode, which indicates that something really went wrong and looks similar to [my case](https://stackoverflow.com/q/57028626/7571258). — zett42, Jul 16 '19 at 08:22
Let's hope this is not related to recent Windows changes ([as mentioned in bullet point 3 towards the top here](https://stackoverflow.com/a/6066263/129130)). — Stein Åsmul, Jul 16 '19 at 10:31
[More on MSI logging](https://stackoverflow.com/a/54458890/129130). And also [check the Event Viewer](https://stackoverflow.com/a/49927626/129130) perhaps. — Stein Åsmul, Jul 16 '19 at 10:37
@Ross did you have a chance to test this on a clean virtual? — Stein Åsmul, Jul 17 '19 at 19:03
@SteinÅsmul the installer worked on the fresh machine and on my workstation! Thank you. — Ross, Jul 18 '19 at 16:46
Are you live with lots of installation, or are you still in development? — Stein Åsmul, Jul 18 '19 at 16:49
@SteinÅsmul This is late development with a beta roll out scheduled for August 1. We plan to run parallel systems during August. With a full switch over in September. — Ross, Jul 18 '19 at 18:52
OK, looks like a "dirty state" for me. It is when errors accumulate and your new fix fails so you have "my fix for my failed fix failed" and all of that. Very common, happens to everyone. *"Resident evil of all things"*. Will have a look at the log. Deployment is migrating from one stable state to another. [Got this piece on the complexity of deployment mid page here](https://stackoverflow.com/a/12101548/129130). — Stein Åsmul, Jul 18 '19 at 19:00
It actually looks like the product was "advertised" instead of installed in the first log. Advertisement puts the product in place to be installed on demand as the users launch shortcuts. Check the SCCM logs and commands used? I have added an answer below commenting on some issues with what is included in the MSI. — Stein Åsmul, Jul 18 '19 at 21:53

Stein Åsmul · Accepted Answer · 2019-07-18T22:08:37.393

Launch Error: That application launch problem is probably a trifle such as a missing runtime. Maybe even the .NET framework itself? (happens to me that one). I would check that first. What other runtimes do you need? Java, Visual Studio C/C++ Runtime, etc...

Launch Error Check-List: I have this "torpedoes full spread check-list" here: Desktop applicaton not opening after installation in client system. Essentially an "ideas list" for what could conceivably be wrong with your launch process. Nowhere near complete, but still big enough to make everyone sigh.

Prerequisites: Having looked at this briefly, it appears there are some problems in this source relating to the inclusion of files that should be installed via runtimes instead of being included as files directly in your own MSI. The runtimes appear to be:

.NET Framework (whichever version applies)
Microsoft Report Viewer (either 2012 or 2015 - not sure which)
Microsoft CLR Types for SQL Server (2012, 2014, 2016 - not sure which)
- Maybe check for it in the Feature Packs.
- Sample 2016 feature pack. Click "Details".

SCCM: You need to deploy these prerequisites / runtimes via their own MSI files available for download from Microsoft. For general purpose distribution you could make a Burn bundle (a setup.exe generator for WiX) or a number of deployment tools that can do the same (Installshield, Advanced Installer, etc...). In your case, you just push them out via SCCM, but hold your horses...

Cleanup: You need to remove the erroneous inclusions of these files in the WiX source, and this will cause side-effects on uninstall and major upgrade (major upgrade uninstalls old versions and installs the new version). MSI files think they "own" whatever files you include in the setup (unless you mark them to not be controlled by MSI). Hence they will try to "rip out" the files you have included. This could cause your application to fail to launch or operate correctly (and also other applications depending on those runtimes). Note that MSI files do not always succeed uninstalling files due to OS-override functions.

Erronous Inclusions: Please remove all files included from the GAC, Visual Studio folders and Reference Assemblies folders. You should generally never include single files from there to deploy. Look for the runtime package. Compile a new MSI and start testing it. Don't test on too many dirty systems please. You can simulate the dirty state by deleting files manually.
Cleanup Process: During the upgrade to the latest version - now without the erronously included runtime files - you may see that these runtime files are "ripped out". Now you need to deploy the prerequisites AFTER you have done the upgrade of the package. This should put the runtime files back in place. Hopefully (there could be other problems).

Dangling Versions: Your previous questions seems to indicate that you may have "dangling versions" on these systems. In order to deal with this I would honestly pull back all deployed software via SCCM and then deploy the newest version and finally the runtimes spoken about above.

Some Links:

Throwing in this old "permission denied" list of fixes: System.UnauthorizedAccessException while running .exe under program files
I want to alert you to the possibility of making WiX source files simpler via new mechanisms to auto-generate a number of attributes when they are not necessary to specify. Please see: Simplifying WiX markup. I would not do this now since you are live, but for future packages you can try this.

I'm sorry it has taken so long to comment on your answer. I am grateful for the time and effort you put into this. Unfortunately much of it is over my head. I have a lot of learning to do on this subject. Any suggestions? As for the Answer, I am not sure what the protocol is. I want you to get credit for your effort, but this 'answer' wasn't what solved my problem. Your suggestion of testing on a clean machine and thoroughly removing the previous installs was what ultimately lead to a solution. So I am not sure how to close this out. Thank you again. — Ross, Aug 30 '19 at 18:15
No worries, what was the actual problem when you found it? I can cook up a shorter answer. — Stein Åsmul, Aug 30 '19 at 18:59
Based on your suggestion to try the installation on a new, clean machine- which worked; I then uninstalled the application from each on my test machines. After that I went through the registries of each machine using a search for "dashboard" and deleted any reference to my application- there were quite a few orphaned references. Once I finished that the current incarnation of my installer worked properly on all of them. So the problem ultimately was garbage left over from earlier installers made using other tools. — Ross, Sep 05 '19 at 18:23

WiX Installer Claims Success but takes no real action

1 Answers1