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 110 matching lines @@
       Languages="$(var.SupportedLanguages)"
       Compressed="yes"
       InstallScope="perMachine" InstallPrivileges="elevated"
     />
     <!--
       The MajorUpgrade tag allows us to specify the relationship between our
       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.
+      The default value for @Schedule attribute is afterInstallValidate.
+      If we used that it would be possible to endup in a state when one
+      version is uninstalled and another is not installed. We use 
+      afterInstallInitialize here and not afterInstallExecute since we need to
+      make sure we uninstall SimpleAdblock *before* we install ABP.
+      SimpleAdblock and ABP for IE are using the same CLSID and SimpleAdblock's
+      uninstallation is running DllUnregisterServer which removes the CLSID
+      from the registry.
     -->
     <MajorUpgrade
       Schedule="afterInstallInitialize"

[Eric, 2015/03/27 12:51:45]

Please see the comment immediately about about why the 'Schedule' attribute was
set that way. Getting rid of atomicity is asking for trouble.

I don't see any documentation about why this would be scheduled differently.

[Oleksandr, 2015/04/16 09:58:09]

ABP for IE and SimpleAdblock have the same CLSID when registering into COM. When
uninstalling Simple Adblock the registry key gets removed, so this is why we
want to uninstall it before installing ABP for IE. What can possibly go wrong if
we run on afterInstallInitialize? The worst thing I can think of is that old
version gets uninstalled and new version fails to install. Is that it?

[sergei, 2015/04/22 10:37:08]

"afterInstallInitialize" still implies that uninstalling can be rolled back if
either installing or uninstalling fails because "InstallInitialize" action marks
the beginning of the "deferred" stage of the Execute sequence.

I would also like to see edited the comment regarding `Schedule` attribute. It
should explain that in comparison with the default value "afterInstallValidate"
(which can lead to a state without any version installed) we use
"afterInstallInitialize", so it's executed at the deferred stage and can be
rolled back in case of failure either of uninstalling (RemoveExitingProducts
standard action) or installing. As well as it can not be after
"afterInstallExecute" because in this case uninstalling would remove important
registry keys (in particular COM CLSID).

PS: I have not checked how we create registry keys yet, however I would expect
them to be not removed for Schedule="afterInstallExecute" because reference
counter should prevent it. But anyway I think that
Schedule="afterInstallInitialize" is safer because in this case the whole
procedure looks more straightforward and not affected by actions (in particular
possible custom actions) which don't use reference counters.

[Oleksandr, 2015/04/24 11:50:32]

SimpleAdblock uninstall removes the registry keys using DllUnregisterServer, so
installer is not managing those.

       AllowDowngrades="yes"
     />
     
     <!--Remove Simple Adblock-->
-    <Property Id="SIMPLEADBLOCKDETECTED" Secure="yes"/>
+    <Property Id="SIMPLEADBLOCKPRODUCTCODE" Secure="yes"/>
     <Upgrade Id="27D7C170-67AA-40D9-978F-5F14B4D0FEEE">
        <UpgradeVersion
           Minimum="0.7.0.0" Maximum="99.0.0.0"
-          Property="SIMPLEADBLOCKDETECTED"
+          Property="SIMPLEADBLOCKPRODUCTCODE"
           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 22 matching lines @@
     <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;" 

[Eric, 2015/03/27 12:51:45]

Using "." for current directory is likely not to be as reliable as we'd like.

[Oleksandr, 2015/04/16 09:58:09]

Why not? We are launching in APP_DATA_FOLDER

         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"/>    
-    <InstallExecuteSequence>
+    <Binary Id="installer_ca" SourceFile="$(var.installer_dir)\build\$(var.build_dir)\$(var.CA_Configuration)\installer-ca.dll"/>
+    <InstallUISequence>
       <!--
         The LaunchConditions action occurs near the beginning, before any of the expensive operations.
       -->
       <Custom
         Action="Close_IE"
         After="LaunchConditions"
       />
+    </InstallUISequence>
     
+    <InstallExecuteSequence>
       <Custom 
         Action="CleanupSimpleAdblock" 
-        Before="InstallFinalize"><![CDATA[SIMPLEADBLOCKDETECTED <> ""]]></Custom>
+        Before="InstallFinalize"><![CDATA[SIMPLEADBLOCKPRODUCTCODE <> ""]]></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"/>
@@ skipping 611 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"/>
+      <ComponentRef Id="simpleAdblockMark"/>
     </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 Id="simpleAdblockMark" Guid="cc30c3b0-c713-01e2-7b8b-1800200c9a65">
+          <Condition><![CDATA[SIMPLEADBLOCKPRODUCTCODE <> ""]]></Condition>
+          <RegistryKey Root="HKCU" Key="Software\Adblock Plus for IE">
+            <RegistryKey Key="ConvertedFrom">
+              <RegistryValue Name="name" Type="string" Value="simpleadblock"/>
+            </RegistryKey>
+          </RegistryKey>
         </Component>
       </Directory>
     </DirectoryRef>
 
     <?include ../installer-lib/custom-i18n.wxi ?>
     <?include ../custom-action/close_ie.wxi ?>
   </Product>
 </Wix>