Installer localization and new build system

installer/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.
-  See http://wix.sourceforge.net/faq.html#Error217
+  See http://blogs.msdn.com/b/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx
+    and http://blogs.msdn.com/b/astebner/archive/2007/06/07/3151752.aspx,
+    both taken from (must use the Wayback Machine) http://wix.sourceforge.net/faq.html#Error217 
 -->
 <!--
   These definitions enable compiling multiple versions & Product ID's from the same file.
   This is to allow testing upgrade features without having to switch back and forth between working copies.
 -->
 <?ifdef Version ?>
   <!--
     If we're given a version on the command line, use it.
     We use a short name on the command line for ease of use.
     We use a longer name within this file for clarity about which "version" it is specifically
   -->
   <?define Product_Version=$(var.Version) ?>
 <?else?>
   <?error "Version" parameter is required ?>
 <?endif?>
 
 <?ifndef Configuration ?>
   <?error "Configuration" parameter is required ?>
 <?endif?>
 
 <!--
+  CA_Configuration is the Visual Studio configuration for the Custom Action library.
+  It's set to "Debug" while the installer with a CA is in development.
+  TODO. 
+    First, set this variable based on the configuration in the VS solution.
+    Second, change the default to "Release" (or perhaps an error).
+-->
+<?ifndef CA_Configuration?>
+  <?define CA_Configuration="Debug" ?>
+<?endif?>
+
+<!--
   sys.BUILDARCH is set by the command line argument '-arch'.
   The default value to "x86"
 -->
 <?if $(sys.BUILDARCH)="x86"?>
   <?define Minimum_Version="100"?>
   <?define Program_Files="ProgramFilesFolder"?>
   <?define Product_Name="!(loc.ProductName32)"?>
 <?elseif $(sys.BUILDARCH)="x64"?>
   <?define Minimum_Version="200"?>
   <?define Program_Files="ProgramFiles64Folder"?>
   <?define Product_Name="!(loc.ProductName64)"?>
 <?else?>
   <?error Unsupported value of sys.BUILDARCH=$(sys.BUILDARCH)?>
 <?endif?>
 
+<!--
+  The current directory when the compiler runs is "installer/build/<arch>".
+  Most assets are based in the root directory, three levels up.
+  The custom action library is base in the installer directory, two levels up.
+-->
+<?define plugin_dir="..\..\.." ?>
+<?define installer_dir="..\.." ?>
+
 <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
+  <!--
+    The attributes 'Language' and 'Codepage' are specifications for the database only.
+    Codepage 65001 is UTF-8.
+  -->
   <Product
     Name="$(var.Product_Name)"
     Manufacturer="Eyeo GmbH"
     Version="$(var.Product_Version)"
     Language="!(loc.LANG)" Codepage="1252"
     Id="*"
     UpgradeCode="3a8e3ab4-762d-4641-806e-2dccb953d73f">
 
+    <!--
+      Attribute @Languages
+        The list contains all the languages supported within the MSI, all but the first as embedded transforms.
+        The first language code is the language of the base MSI.
+    -->
+    <!--
+      At the present time, we are not localizing the summary information because of limitations
+        both in Windows Installer and in the tool chain.
+      At a later time, localizing this section requires setting an ANSI codepage
+        and the four attributes Keywords, Description, Comments, and Manufacturer.       
+    -->
+    <!--
+      For the present version, the following languages are omitted because the WiX UI extension has no localizations for them yet.
+      They can be added later, but the build script needs to be changed to accept arguments for the extra localization source.
+        fil-PH. Filipino - Phillipines. LCID = 1124
+        kn-IN. Kanada - India. LCID = 1099
+        mr-IN.  Maratha - India. LCID = 1102
+        ms. Malaysian - generic. LCID = 62
+        nn-NO. Nynorsk - Norway. LCID = 2068
+        ur-PK. Urdu - Pakistan. LCID = 1056
+      They are being omitted by having their decimal LCID left out of the Packages/@Languages attribute below.
+      The build system presently embeds transforms for them, but without their LCID in this list, they won't be recognized.
+      These embedded transforms, however, can be explicitly applied on the command line of msiexec.
+    -->
     <Package
-      Keywords="!(loc.Keywords)"
-      Description="!(loc.Description)"
-      Comments="!(loc.Comments)"
+      SummaryCodepage="1252"
+      Keywords="Installer, Adblock Plus"
+      Description="Adblock Plus for IE"
+      Comments="Thank you for using Adblock Plus."
+      Manufacturer="Eyeo GmbH"
       InstallerVersion="$(var.Minimum_Version)"
-      Languages="!(loc.LANG)" SummaryCodepage="!(loc.CODEPAGE)"
+      Languages="7,1,9,12,16,19,1026,1027,1028,1029,1030,1032,1034,1035,1037,1038,1041,1044,1045,1046,1048,1049,1050,1051,1053,1054,1055,1058,1061,1081,2052,2070"
       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.
     -->
     <MajorUpgrade
       Schedule="afterInstallExecute"
       DowngradeErrorMessage="!(loc.AlreadyInstalled)"
     />
     <MediaTemplate EmbedCab="yes"/>
 
     <!--
       User interface
     -->
     <UIRef Id="custom_WixUI_InstallDir"/>
     <UIRef Id="WixUI_ErrorProgressText"/>
     <Property Id="WIXUI_INSTALLDIR" Value="INSTALLFOLDER"/>
 
     <!--
       Define and schedule a "Custom Action Type 1" to ensure that IE is closed before installation.
       Because WiX is closely tied to the MSI database format, there are multiple tags required to do this.
       The "CustomAction" tag defines the tag itself, but doesn't sequence it;
         it defines an entry in the "CustomAction" table.
       The "Binary" tag describe an asset that's incorporated into the MSI but that is not an installed component.
-      The "Custom" tag defines the sequencing of an action;
-        it defines an entry in one of the sequence tables (there are six).
+      The "Custom" tag defines when the action executes by defining an entry in one of the sequence tables.
       
       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="abp_close_applications"
         Return="check"
     />
-    <Binary Id="installer_ca" SourceFile="build\ia32\Debug\installer-ca.dll"/>    
+    <!--
+      Note that we're using a 32-bit custom action library for both 32- and 64-bit installers. 
+    -->
+    <Binary Id="installer_ca" SourceFile="$(var.installer_dir)\build\ia32\$(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>
 
@@ skipping 116 matching lines @@
       The present installer is a per-machine installer.
       That means it writes to HKEY_LOCAL_MACHINE, so that all users on the machine will have the BHO installed.
       It's possible to write keys to HKEY_CURRENT_USER in a situation where that's not desirable, if needed.
     -->
     <ComponentGroup Id="Binaries" Directory="INSTALLFOLDER">
       <!--
         The 32-bit version of the DLL is included in both 32- and 64-bit installers.
         We need an explicit value for attribute @Win64 so that the ARCH argument does not override its implicit value.
       -->
       <Component Id="AdblockPlus32.dll" Guid="d9a35780-d712-11e2-8b8b-0800200c9a66" Win64="no">
-        <File Id="AdblockPlus32.dll" Name="AdblockPlus32.dll" Source="..\build\ia32\$(var.Configuration)\AdblockPlus.dll" KeyPath="yes" Checksum="yes">
+        <File Id="AdblockPlus32.dll" Name="AdblockPlus32.dll" Source="$(var.plugin_dir)\build\ia32\$(var.Configuration)\AdblockPlus.dll" KeyPath="yes" Checksum="yes">
           <?include dll_class.wxi ?>
         </File>
         <?include bho_registry_value.wxi ?>
       </Component>
       <!--
         The 64-bit version of the DLL is only included in the 64-bit installer.
         We don't really need an explicit value for attribute @Win64, but it's there for resilience.
 
         Note that the <Class> element and the <RegistryKey> element are duplicated from the 32-bit version.
         We use "include" directives to ensure that they are identical.
         They have to be the same to support both the 32- and 64-bit versions of Internet Explorer on a 64-bit system.
         IE uses the same algorithm to search for BHO regardless of platform,
           so with two versions of IE, we need two identical registrations.
         The 32-bit version on a 64-bit system will be registered under "Wow6432Node" translated keys,
           while the 64-bit version will be under the keys as they appear in this source, not translated.
         We don't need to put in the "Wow6432Node" registry key explicitly;
           something in Windows Installer takes care of the mapping transparently.
       -->
       <?if $(sys.BUILDARCH)="x64"?>
         <Component Id="AdblockPlus64.dll" Guid="ed77a2c0-d712-11e2-8b8b-0800200c9a66" Win64="yes">
-          <File Id="AdblockPlus64.dll" Name="AdblockPlus64.dll" Source="..\build\x64\$(var.Configuration)\AdblockPlus.dll" KeyPath="yes" Checksum="yes">
+          <File Id="AdblockPlus64.dll" Name="AdblockPlus64.dll" Source="$(var.plugin_dir)\build\x64\$(var.Configuration)\AdblockPlus.dll" KeyPath="yes" Checksum="yes">
             <?include dll_class.wxi ?>
           </File>
           <?include bho_registry_value.wxi ?>
         </Component>
       <?endif?>
 
       <!--
         The engine must go into the same directory as the DLL, since that location is searched explicitly (and uniquely).
       -->
       <?if $(sys.BUILDARCH)="x86"?>
         <Component Id="AdblockPlusEngine.exe" Guid="f45572c0-d712-11e2-8b8b-0800200c9a66" Win64="no">
-          <File Id="AdblockPlusEngine.exe" Source="..\build\ia32\$(var.Configuration)\AdblockPlusEngine.exe" KeyPath="yes" Checksum="yes"/>
+          <File Id="AdblockPlusEngine.exe" Source="$(var.plugin_dir)\build\ia32\$(var.Configuration)\AdblockPlusEngine.exe" KeyPath="yes" Checksum="yes"/>
         </Component>
       <?elseif $(sys.BUILDARCH)="x64"?>
         <Component Id="AdblockPlusEngine.exe" Guid="fa8d65d0-d712-11e2-8b8b-0800200c9a66" Win64="yes">
-          <File Id="AdblockPlusEngine.exe" Source="..\build\x64\$(var.Configuration)\AdblockPlusEngine.exe" KeyPath="yes" Checksum="yes"/>
+          <File Id="AdblockPlusEngine.exe" Source="$(var.plugin_dir)\build\x64\$(var.Configuration)\AdblockPlusEngine.exe" KeyPath="yes" Checksum="yes"/>
         </Component>
       <?endif?>
     </ComponentGroup>
 
     <!--
       The HTML_Tree component group contains all the files in the HTML folder.
       Individual file entries within a single component group must all be in the same directory.
       Also, ComponentGroup is not a valid child of ComponentGroup, so subdirectories are linked by reference.
     -->
     <ComponentGroup Id="HTML_Tree">
@@ skipping 20 matching lines @@
       <ComponentRef Id="html_static_js_IESettings.js"/>
       <ComponentRef Id="html_static_js_ieFirstRun.js"/>
       <ComponentRef Id="html_static_js_settings.js"/>
       <ComponentRef Id="html_static_js_vendor_DD.belatedPNG.js"/>
       <ComponentRef Id="html_static_js_vendor_html5shiv.js"/>
       <ComponentRef Id="html_templates_firstRun.html"/>
       <ComponentRef Id="html_templates_index.html"/>
     </ComponentGroup>
 
     <DirectoryRef Id="HTML_Folder">
-      <Directory Id="html" FileSource="..\html">
+      <Directory Id="html" FileSource="$(var.plugin_dir)\html">
         <Directory Name="static" Id="html_static">
           <Directory Name="css" Id="html_static_css">
             <Component Id="html_static_css_firstRun.css" Guid="facb02d0-f073-11e2-b778-0800200c9a66">
               <File Name="firstRun.css"/>
             </Component>
             <Component Id="html_static_css_settings.css" Guid="07173c90-d713-11e2-8b8b-0800200c9a66">
               <File Name="settings.css"/>
             </Component>
           </Directory>
           <Directory Name="img" Id="html_static_img">
@@ skipping 167 matching lines @@
         <ComponentRef Id="locales_ur_PK.ini"/>
         <ComponentRef Id="locales_uz.ini"/>
         <ComponentRef Id="locales_vi.ini"/>
         <ComponentRef Id="locales_xh.ini"/>
         <ComponentRef Id="locales_zh_CN.ini"/>
         <ComponentRef Id="locales_zh_HK.ini"/>
         <ComponentRef Id="locales_zh_TW.ini"/>
         <ComponentRef Id="locales_zu.ini"/>
     </ComponentGroup>
     <DirectoryRef Id="Locales_Folder">
-      <Directory Id="locales" FileSource="..\locales">
+      <Directory Id="locales" FileSource="$(var.plugin_dir)\locales">
         <Component Id="locales_af.ini" Guid="0311a948-3e76-45e8-83c0-8455fa9083b7">
           <RemoveFile Id="af.ini" Name="af.ini" On="install"/>
         </Component>
         <Component Id="locales_am.ini" Guid="cca25e4e-9b74-4e99-a592-c54a310fe806">
           <RemoveFile Id="am.ini" Name="am.ini" On="install"/>
         </Component>
         <Component Id="locales_ar.ini" Guid="2e25459f-e7e0-40bf-b9d2-05a60be967f9">
           <File Name="ar.ini"/>
         </Component>
         <Component Id="locales_as.ini" Guid="871517f1-be55-4b8c-83b9-5da89230de6b">
@@ skipping 234 matching lines @@
       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"/>
     </ComponentGroup>
     <DirectoryRef Id="ABP_APPDATA_FOLDER">
-      <Directory Id="ini" FileSource="..\files">
+      <Directory Id="ini" FileSource="$(var.plugin_dir)\files">
         <Component Id="ini_settings.ini" Guid="dc30c3b0-d713-11e2-8b8b-0800200c9a66">
           <File Name="settings.ini"/>
         </Component>
       </Directory>
     </DirectoryRef>
   </Product>
 </Wix>