Bootstrapper Error 0x8013101b: Failed to create the managed bootstrapper application.

I developed Wix Burn based Managed bootstrapper, which required .Net Framework v4.0.xxx. It worked perfectly fine when I tried on Windows XP + Service Pack 2. That is, it initially launched .Net FW 4 Setup, which I packed in my Burn Package, and then launched my Boostrapper Installer.

But on Windows 7 without Service Pack 1, it was crashing with following log:

[0530:0B50][2014-01-21T11:39:50]i000: Loading managed bootstrapper application.

[0530:0B50][2014-01-21T11:39:51]e000: Error 0x8013101b: Failed to create the managed bootstrapper application.

[0530:0B50][2014-01-21T11:39:51]e000: Error 0x8013101b: Failed to create UX.

[0530:0B50][2014-01-21T11:39:51]e000: Error 0x8013101b: Failed to load UX.

[0530:0B50][2014-01-21T11:39:51]e000: Error 0x8013101b: Failed while running 

.

After some searching and digging, I finally able to solve it by editing BootstrapperCore.config file. Initially, it was:

< startup useLegacyV2RuntimeActivationPolicy="true" >
        < supportedRuntime version="v4.0" / >
        < supportedFramework version="v4\Client" / >
         < supportedRuntime version="v2.0.50727" / >

< /startup>
         

I removed < supportedRuntime version="v2.0.50727" / >. This causes bootstrapper to launch .Net FW 4.0 installation (Packed with as payload). 

Remember, on Windows 7 without SP1, there is .Net framework 3.5. So supportedRuntime version="v2.0.50727" causing the bootstrapper trying to use Net FW 2.0 or 3.5 and so failing, as my Bootstrapper is based on .Net FW 4.

Now, t updated the machine with .Net FW 4 and then launched my bootstrapper, and now working like charm.. :) 

Executing Custom Actions on the basis of Feature Selection.

I came across this situation that my user has to make selection from Customize Dialog (shows feature tree) and depending upon this selection Custom Actions (actually calls to RegSvr32.exe) have to be executed.

For this, I added a Feature Structure to be shown to user as a Choice options:

    <Feature Id="RegShellExtensions" Level="1" Display="expand" Title="Register Shell Extensions" Description="Register shell extensions with windows" >
      <FeatureId="ShellExtx86" Title="32 Bit Shell Extensions"  Description="Register 32 Bit Shell Extensions" Level="1" />
      <?if $(var.PACKAGE_TARGETPLATFORM)=x64?>
      <Feature Id="ShellExtx64" Title="64 Bit Shell Extensions"  Description="Register 64 Bit Shell Extensions" Level="1" />
      <?endif?>
    </Feature>

So depending upon which feature user would select, it is referenced in InstallExecuteSequence table to schedule the CustomActions accordingly:

    <InstallExecuteSequence>
      <Custom Action="RegisterIsmShellMenu" After="CostFinalize">
        <![CDATA[(NOT Installed) AND (&ShellExtx86=3) AND NOT(!ShellExtx86=3)]]>
      </Custom>
     
      <?if $(var.PACKAGE_TARGETPLATFORM)=x64?>
        <Custom Action="RegisterIsmShellMenuX86" After="CostFinalize">
          <![CDATA[(NOT Installed) AND (&ShellExtx64=3) AND NOT(!ShellExtx64=3)]]>
        </Custom>
      <?endif?>
    </InstallExecuteSequence>

Important:The term "&ShellExtx86=3" means the action is to install the feature local. The term "NOT(!ShellExtx86=3)" means the feature is not installed local.

For more examples, see Examples of Conditional Statement Syntax.

For Conditional Statement Syntax, see Conditional Statement Syntax

Making Merge Modules (msm) more configurable…

I rarely have to face this, but have to, that is: develop merge modules which can be configured at runtime. Recently, I developed a merge module which is to write it files location in an INI file. And the location of INI file can’t be hard coded inside. So using  Configuration and  Substitution elements, we can achieve this goal. Here is the code segment:

Wix Merge Module using Configuration and Substitution elements:

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Module Id="FasterGPS"
          Language="1033"
          Version="1.0.0.0">
    <Package Id="{4DDF212E-E8A8-47E6-A010-DDF8D763866C}"
             InstallerVersion="200"
             Manufacturer="PUT-COMPANY-NAME-HERE" />
    <Configuration Name="CONFIGURABLE_AT_INI_FOLDER"
                   Format="Key"
                   Type="Directory"
                   ContextData="IsolationDir"
                   DefaultValue="INSTALLDIR"
                   NonNullable="yes"
                   DisplayName="AT.ini Folder"
                   Description="AT.ini Folder" />
    <Substitution Table="Directory"
                  Row="INI_FOLDER"
                  Column="Directory_Parent"
                  Value="[=CONFIGURABLE_AT_INI_FOLDER]" />
    <Directory Id="TARGETDIR"
               Name="SourceDir">
      <Directory Id="INI_FOLDER" />
      <Directory Id="ME">
        <Component Id="FasterGPS.apk"
                   Guid="{B43FA0CC-4C3D-481B-8521-4667D7701D37}">
          <File Id="FasterGPS.apk"
                KeyPath="yes"
                Source="FasterGPS.apk" />
          <IniFile Id="MyLocationINI"
                   Action="createLine"
                   Directory="INI_FOLDER"
                   Key="CUSTOM_ROOT"
                   Name="MyConfig.ini"
                   Section="ALIAS"
                   Value="[ME]" />
        </Component>
      </Directory>
    </Directory>
  </Module>
</Wix>

Now when you use the merge module, you will have to define ConfigurationData element as mentioned below:

WIX passing Configuration Data to Merge Module:

<Directory Id="MY_INI_FOLDER" >
  <Component Id="MyINIFile"
             Guid="{52B0F9A2-E91C-4CE3-B3A8-0F29EC45DBF3}">
    <File Id="MyINIFile"
          KeyPath="yes"
          Source="MyConfig.ini" />
  </Component>
</Directory>
<Directory Id="SUB"
           Name="Sub apps">
  <Merge Id="FG"
         DiskId="1"
         SourceFile="FasterGPS.apk.msm"
         Language="1033" >
    <ConfigurationData Name="CONFIGURABLE_AT_INI_FOLDER"
                       Value="MY_INI_FOLDER" />
  </Merge>
</Directory>

At run time, value of "MY_INI_FOLDER" would be passed to merge module and would be received in CONFIGURABLE_AT_INI_FOLDER and would be Substituted in Directory Table record for "INI_FOLDER";

MSI: Admin install doesn’t extract all files…

While working with a Patch using Wix Patching, I did an Admin Install. But Pyro.exe complains that some files cannot be found. When I searched these in the output directory where Admin Installation deployed its files, those files were really missing. These were however present in msi and mentioned in Files table.

After some investigation, I got to know that the Feature with which these were attached, had a default Level=0 (Level 0 would disable the feature and so it will never install) and that’s the main cause that Admin Install was not installing these files.

So, by using Microsoft Orca, I simply changed the value in level Column from 0 to 3. (Or any other value greater than 0).

And now Admin Install worked accordingly and Pyro.exe was also happy to give me my required patch.

There might be many reasons for keeping a Feature Level=0. During installation, there might be some Custom Action changing the Level or any condition accordingly. And that Custom Action or Condition might not be evaluated/scheduled during Admin Install.