title: Forcing WiX Burn bootstrapper to allow MSI files to use REINSTALLMODE=amus
body: <p>Since I wasn't a part of my company when our build process was designed and implemented (and has been successful for quite a few years now), I found out that there were things that were being done that may be looked at as 'hacks' to MSI 'purists'. However, in order to get a workable installer with <a href="http://en.wikipedia.org/wiki/Microsoft_Visual_Studio#Visual_Studio_2012" rel="nofollow">Visual Studio 2012</a>, I've been doing the best I can to mimic what was being done with the <code>.vdproj</code> files in <a href="http://en.wikipedia.org/wiki/Microsoft_Visual_Studio#Visual_Studio_2010" rel="nofollow">Visual Studio 2010</a>. Of the many snags I've hit, this one seems to be the last one that I can't resolve.</p>
  
  <p>As part of our build process with Visual Studio 2010, we built our code and created a Framework MSI on one VM. Then we took that Framework MSI and installed it on a different VM. After the framework had been installed, we built our product code and created a Product MSI off of it. This created a Product dependence on our Framework. What this meant was that when installing on a client machine, the bootstrapper needed to install the Framework first followed by the Product. On uninstall our documentation stated to either have it handled through ARP or by command line '<code>msiexec /x {Product.msi/@ProductCode}</code>' and then the '<code>msiexec /x {Framework.msi/@ProductCode}</code>'.</p>
  
  <p>At the time, management determined that the <code>ProductCode</code> would be the easiest way for other product teams to determine if our product had been installed on a machine. This lead them to the decision that they needed to keep a static <code>ProductCode</code> for both the Framework and the Product.</p>
  
  <p>In order to handle upgrades, they had to create a <code>ProductTool.exe</code> that was nothing more than the msiexec wrapped in an executable that took a <code>/ProductCode={@ProductCode}</code> argument.</p>
  
  <p>As part of our bootstrapper, they called:</p>
  
  <ul>
  <li>Install prerequisites (<a href="http://en.wikipedia.org/wiki/Windows_Installer#Versions" rel="nofollow">Windows Installer 4.5</a>, .NET 3.5 SP1, SQL Server 2008 R2 Express, <a href="http://en.wikipedia.org/wiki/Microsoft_Sync_Framework" rel="nofollow">Sync</a> 2.1)</li>
  <li><code>ProductTool.exe</code> (<code>Product.msi</code> -- to uninstall the Product.msi)</li>
  <li><code>ProductTool.exe</code> (<code>Framework.msi</code> -- to uninstall the Framework.msi)</li>
  <li>Install <code>Framework.msi</code></li>
  <li>Install <code>Product.msi</code></li>
  </ul>
  
  <p>However, I didn't discover until just recently that the <a href="http://en.wikipedia.org/wiki/WiX#Burn" rel="nofollow">Burn</a> bootstrapper does not allow <code>REINSTALLMODE=amus</code>. In the install logs, it says that it changes it to <code>REINSTALLMODE=vomus</code>. Apparently in order to get that aforementioned process to work on upgrades, they had to set <code>REINSTALLMODE=amus</code>.</p>
  
  <p><strong>UPDATE</strong>: I finally got to talk to the original developer of the installer and found out that <code>REINSTALLMODE=amus</code> was used intentionally to revert all of the versioned files (assemblies, DLL files, etc.) and non-versioned files (.config, SQL script, etc.) as a risk minimization and robustness/"self-healing" strategy.</p>
  
  <p>Having said all of that, is it even possible with a standard burn bootstrap application (BA) to set <code>REINSTALLMODE=amus</code> so that I can get the upgrades working? The MSI files have the Property's set, but Burn seems to override it.</p>