Burn (WiX bootstrapper) does not uninstall MSI package

Question

I have a Burn bundle with this chain:

<Chain>
  <PackageGroupRef Id="NetFx40Web"/>
  <MsiPackage SourceFile="c:\\My\\Path\\MyMsi.msi"
        Id="MyMsi" DisplayName="MyMsi" DisplayInternalUI="yes" Vital="yes">
    <MsiProperty Name="INSTALLLOCATION" Value="[InstallFolder]" />
  </MsiPackage>
</Chain>

Both .NET framework and my MSI files are installed correctly. But the MSI package is not uninstalled during uninstall procedure (both after clicking on the bootstrapper EXE or from Programs And Features). Is there some way how to force uninstalling the MSI package?

Fiddlewood

Answer 1

Burn will create a log file with detailed information about the change state of each package in %TEMP%. Take a look at the section called "Plan" and you will see lines for each package in your Bundle. Other messages in the log file will point out if the MSI is still reference counted by another Bundle or if the MSI on the machine is newer than the one the Bundle carries (so it won't uninstall it).

Vlf

Thank you. The MSI was listed as referenced, because there were some screwed values in windows registry. – Fiddlewood

Answer 2

I experienced the same problem of an MSI not uninstalling when removing the bundle and the reason turned out to be quite simple.

The MSI was created in the same Visual Studio solution and it was set as a dependency of the bundle project. Every time the bundle was created, the MSI was created first.

The root cause of the uninstall not happening was the product key of the MSI being set to "*" and thus be changed every time it was created. This somehow prevented the removal. When set to a fixed GUID, the uninstall was successful.

Edit: Turns out, I did something special. I created a German and an English version (called light.exe twice) and (with some external scripts) merged them together into one MSI. So, the German version had a different product ID as the English one. Uninstall worked properly either in German or English Windows, depending on which one light.exe was called first.

Ossetic