Issue 1103 - Migrate Simple Adblock users

installer/src/msi/adblockplusie.wxs

 <?xml version="1.0" encoding="UTF-8"?>
 <!--
   Compilation Note:
   You may see linking errors that look like these:
     <quote>LGHT0217 : Error executing ICE action 'ICExx' [...] The error code is 2738.</quote>
   The documentation for this error code talks about custom actions,
     even though the CustomAction keyword does not appear in this source.
   Certain WiX elements are implemented by MSI custom actions,
     which means this source implicitly declares some insofar as the Windows Installer sees it.
   These errors are benign and can be avoided by some fiddling with the registry on the development machine.
@@ skipping 116 matching lines @@
       version number and the one installed. The attribute Disallow="no" is
       implied and allows major upgrades to be performed. Downgrades aren't
       allowed by default.
 
       The @Schedule attribute looks a little opaque.
       Suffice it to say that it's the only option for scheduling where uninstallation of the previous version
         and installation of the present version is _always_ going to act atomically.
       It's a shame that you to even explicitly make that choice.
     -->
     <MajorUpgrade
-      Schedule="afterInstallExecute"
+      Schedule="afterInstallInitialize"
       AllowDowngrades="yes"
     />
+    
+    <!--Remove Simple Adblock-->
+    <Property Id="SIMPLEADBLOCKDETECTED" Secure="yes"/>
+    <Upgrade Id="27D7C170-67AA-40D9-978F-5F14B4D0FEEE">
+       <UpgradeVersion
+          Minimum="0.7.0.0" Maximum="99.0.0.0"
+          Property="SIMPLEADBLOCKDETECTED"
+          IncludeMinimum="yes" IncludeMaximum="no" IgnoreRemoveFailure="no"/>
+    </Upgrade>
     <MediaTemplate EmbedCab="yes"/>
 
     <!--
       User interface
     -->
     <UIRef Id="custom_WixUI_InstallDir"/>
     <UIRef Id="WixUI_ErrorProgressText"/>
     <Property Id="WIXUI_INSTALLDIR" Value="INSTALLFOLDER"/>
     
     <!--
@@ skipping 16 matching lines @@
       Attribute "Return" sets the "Custom Action Return Processing Options" to zero,
         which indicates to block the installer until the action completes
         and to treat a non-zero return value from the action as an error.
     -->
     <CustomAction
         Id="Close_IE"
         BinaryKey="installer_ca"
         DllEntry="AbpCloseIe"
         Return="check"
     />
+    
+    <CustomAction 
+        Id="CleanupSimpleAdblock" 
+        Directory="APP_DATA_FOLDER" 
+        ExeCommand="cmd /C &quot;rmdir /s /q &quot;.\Simple Adblock&quot;&quot;" 
+        Execute="deferred" 
+        Return="ignore" 
+        HideTarget="no" 
+        Impersonate="no" />    
     <!--
       We require a 32-bit DLL for the 32-bit installer, and likewise for 64-bit.
       The 64-bit Close_IE action needs to examine 64-bit processes on the system, which are invisible to 32-bit processes.
     -->
     <Binary Id="installer_ca" SourceFile="$(var.installer_dir)\build\$(var.build_dir)\$(var.CA_Configuration)\installer-ca.dll"/>    
-    <InstallUISequence>
+    <InstallExecuteSequence>
       <!--
         The LaunchConditions action occurs near the beginning, before any of the expensive operations.
       -->
       <Custom
         Action="Close_IE"
         After="LaunchConditions"
       />
-    </InstallUISequence>
+    
+      <Custom 
+        Action="CleanupSimpleAdblock" 
+        Before="InstallFinalize"><![CDATA[SIMPLEADBLOCKDETECTED <> ""]]></Custom>
+    </InstallExecuteSequence>
 
     <!--
       We have only a single feature, since there aren't any optional parts.
       The display is hidden for the same reason; there's nothing to choose from.
     -->
     <Feature Id="ProductFeature"
       Title="!(loc.Title)" Description="!(loc.UI_Description)"
       Display="hidden">
       <ComponentGroupRef Id="Installation_Folders"/>
       <ComponentGroupRef Id="Binaries"/>
@@ skipping 610 matching lines @@
 
       The settings.ini file should not be installed this way, since it contains user-generated data.
       A component in Windows Installer represents a fixed piece of data with the MSI, not a changing one.
       The present method of making settings.ini a component is simply an expedient for the present,
         not a permanent solution.
       The correct solution requires the application to manage this file; the installer can't do it right.
       See http://stackoverflow.com/questions/357911/manage-configuration-files-with-wix
     -->
     <ComponentGroup Id="INI_Files">
       <ComponentRef Id="ini_settings.ini"/>
+      <ComponentRef Id="simpleAdblockPrefs"/>
     </ComponentGroup>
     <DirectoryRef Id="ABP_APPDATA_FOLDER">
       <Directory Id="ini" FileSource="$(var.plugin_dir)\files">
         <Component Id="ini_settings.ini" Guid="dc30c3b0-d713-11e2-8b8b-0800200c9a66">
           <File Name="settings.ini"/>
         </Component>
+        <Component Id="simpleAdblockPrefs" Guid="cc30c3b0-c713-01e2-7b8b-1800200c9a65">
+          <Condition><![CDATA[SIMPLEADBLOCKDETECTED <> ""]]></Condition>
+          <File Name="prefs.json"/>
+        </Component>
       </Directory>
     </DirectoryRef>
 
     <?include ../installer-lib/custom-i18n.wxi ?>
     <?include ../custom-action/close_ie.wxi ?>
   </Product>
 </Wix>